This is an MCP server for searching, reading, and managing Raindrop.io bookmarks via the official API.
List collections: View root and nested bookmark collections.
List tags: Show tag names and bookmark counts, optionally scoped to one collection.
Search/list bookmarks: Use Raindrop.io's native search syntax, filter by collection, paginate, sort, and get compact bookmark summaries.
Get bookmark details: Fetch a single bookmark's full useful fields by ID.
Create bookmarks: Add a bookmark with required link, optional metadata, tags, collection, and parsing.
Update bookmarks: Modify specific fields of an existing bookmark and optionally reparse metadata.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@raindrop-mcp search my bookmarks for MCP servers"
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.
A small, auditable local Python MCP server for searching and managing bookmarks
through the official Raindrop.io REST API. It is an unofficial integration that
uses the MCP Python SDK, httpx, and stdio transport.
Tool | Access | Description |
| Read | List root and nested collections. |
| Read | List tag names and bookmark counts, optionally for one collection. |
| Read | List bookmarks or search with Raindrop.io's native syntax. |
| Read | Get one bookmark by ID. |
| Write | Create a bookmark. |
| Write | Update supplied fields on a bookmark. |
Related MCP server: Raindrop.io MCP Server
Python 3.10 or newer
A Raindrop.io test token for your own account
uv sync --extra test
cp .env.example .envOpen the Raindrop.io integrations settings,
create an application, and select Create test token. Add that token to your
local .env file:
RAINDROP_ACCESS_TOKEN=your-test-tokenUse the test token, not the Client ID or Client Secret. Never commit or share
the populated .env file.
Add the following to ~/.codex/config.toml, replacing the working directory
with the absolute path to your clone:
[mcp_servers.raindrop]
command = "uv"
args = ["run", "--env-file", ".env", "raindrop-mcp"]
cwd = "/absolute/path/to/raindrop-mcp-server"
enabled = true
default_tools_approval_mode = "writes"
[mcp_servers.raindrop.tools.list_collections]
approval_mode = "approve"
[mcp_servers.raindrop.tools.list_tags]
approval_mode = "approve"
[mcp_servers.raindrop.tools.search_bookmarks]
approval_mode = "approve"
[mcp_servers.raindrop.tools.get_bookmark]
approval_mode = "approve"Restart Codex after saving the configuration. Read tools are approved by the per-tool settings; create and update remain subject to write approval.
Running uv run --env-file .env raindrop-mcp directly starts the stdio server
and waits for an MCP host. The server must not print application output to
stdout because stdout carries MCP protocol messages.
Collection ID 0 searches all bookmarks.
list_tags defaults to all collections (collection_id=0); pass a collection
ID to scope the API request. Child collections are not fetched separately.
Results contain items: [{"tag": "api", "count": 100}] and a top-level
count representing the number of tags, not bookmarks.
Omit query to list bookmarks, or provide Raindrop.io's native search syntax.
Search pages are zero-indexed, default to 20 items, and allow at most 50.
Searches default to relevance; listings default to newest first.
Search returns compact bookmark summaries; use get_bookmark for detail.
An omitted important field is returned as false; explicit non-boolean
values still fail response validation.
Heavy API metadata such as media, cache data, and highlights is omitted from MCP responses.
Create and update map collection_id to Raindrop.io's
{"collection": {"$id": ...}} request shape.
Write tools do not perform implicit follow-up reads. update_bookmark
returns a compact acknowledgement (id, updated, and updated_fields)
instead of exposing the full Raindrop.io update response.
MCP tool annotations describe read, mutation, idempotency, and external-service behavior to clients. These annotations are hints, not access controls.
parse_metadata and reparse_metadata map to the official pleaseParse: {}
request field.
The server reads credentials only from RAINDROP_ACCESS_TOKEN.
.env and other local environment files are ignored by Git; only the empty
.env.example template is tracked.
API response bodies are not included in raised error messages.
Tests use fake tokens and httpx.MockTransport; they never call Raindrop.io.
uv run pytestThis project is licensed under the MIT License.
Create a bookmark; link is required and metadata parsing is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | ||
| note | No | ||
| tags | No | ||
| cover | No | ||
| title | No | ||
| excerpt | No | ||
| important | No | ||
| collection_id | No | ||
| parse_metadata | No |
| Name | Required | Description |
|---|---|---|
| item | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-read-only, non-destructive mutation. The description adds a useful behavioral detail beyond annotations: metadata parsing is enabled, meaning the tool will parse metadata from the provided link. This does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the core purpose front-loaded and no filler words. It is appropriately concise, though the brevity contributes to the parameter-semantics gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally sufficient for a basic call because it states link is required and metadata parsing is enabled, while the output schema and annotations cover return shape and safety. However, with nine parameters and no explanations for most of them, the description is not complete enough for confident, richer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only addresses link and parse_metadata, both of which are already visible in the schema. The seven optional parameters (note, tags, cover, title, excerpt, important, collection_id) receive no semantic explanation, so the description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Create a bookmark') that clearly separates it from the sibling operations list_collections, search_bookmarks, get_bookmark, and update_bookmark. It also adds the scoping constraints that link is required and metadata parsing is enabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use create_bookmark versus update_bookmark, or when not to use it. The only usage clue is implied by the verb 'Create' and the statement that link is required; no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one bookmark by its positive Raindrop.io ID.
| Name | Required | Description | Default |
|---|---|---|---|
| bookmark_id | Yes |
| Name | Required | Description |
|---|---|---|
| item | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the safe-read nature is covered. The description adds the 'positive ID' constraint, but discloses no additional behavioral traits such as not-found behavior or response characteristics. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no wasted words. The core action is front-loaded, and the identifying constraint is included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema and annotations covering read-only behavior, the description is complete. No prerequisites, side effects, or return-value explanations are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 by explaining that bookmark_id is a Raindrop.io ID and must be positive, which adds meaningful validation context beyond the bare integer type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get one bookmark' by its 'positive Raindrop.io ID.' It clearly differentiates this from sibling tools like list_collections or search_bookmarks by specifying a single item lookup by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this when you need a single bookmark and already know its ID. However, the description does not explicitly state when not to use it or mention alternatives like search_bookmarks for finding bookmarks without an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Raindrop.io collections, including nested collections by default.
| Name | Required | Description | Default |
|---|---|---|---|
| include_children | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds the nested-collection default behavior, which is useful, but does not disclose pagination, ordering, or collection scope beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence states the operation, resource, and the key behavioral default with no filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation with an output schema and read-only annotations, this description is nearly complete. It could mention what include_children=false returns or any pagination, but the current text gives enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden for the single parameter. 'Including nested collections by default' clarifies what include_children controls, adding meaning beyond the bare boolean schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Raindrop.io collections'), and the nested-collections detail distinguishes it from the sibling bookmark tools. An agent can understand exactly what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The resource name makes it clear this is for collections rather than bookmarks, and the default-behavior mention signals the common use case. It does not explicitly name alternatives or state when not to use it, but the sibling context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bookmarks or search with native Raindrop.io syntax.
collection_id 0 searches all bookmarks; page numbering starts at zero. Results default to relevance for searches and newest first for listings.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| query | No | ||
| nested | No | ||
| per_page | No | ||
| collection_id | No |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| count | Yes | |
| items | Yes | |
| per_page | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds genuinely useful behavioral details beyond annotations: collection_id 0 means all bookmarks, page numbering is zero-based, and default ordering differs between searches (relevance) and listings (newest first). This is valuable non-obvious context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, no filler, and the most important information is front-loaded. Every sentence adds functional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the most important defaults and scoping behavior, and the output schema handles return-value expectations. However, with six optional parameters and no schema-level descriptions, the lack of query syntax details and nested/per_page semantics leaves the tool only moderately complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explains collection_id and page, and hints at sort behavior, but the query parameter is only referenced as 'native Raindrop.io syntax' without elaboration, and nested and per_page are left completely unexplained. The description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('bookmarks') and the two modes ('List' or 'search') with a specific verb. It is clearly distinguishable from sibling tools like list_collections and get_bookmark, even without reading their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is appropriate: listing bookmarks or searching them with Raindrop.io syntax. It does not explicitly contrast with siblings or state when not to use it, but the intended use cases are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update only the supplied fields on one bookmark.
| Name | Required | Description | Default |
|---|---|---|---|
| link | No | ||
| note | No | ||
| tags | No | ||
| cover | No | ||
| title | No | ||
| excerpt | No | ||
| important | No | ||
| bookmark_id | Yes | ||
| collection_id | No | ||
| reparse_metadata | No |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| updated | Yes | |
| updated_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is mutating and destructive, so the description need not restate that. It adds the important behavioral trait that unspecified fields are left untouched and that the operation targets exactly one bookmark. It does not go into null-clearing semantics or side effects, so it provides modest added transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the verb and scope, with no filler. It earns its single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the core call contract is mostly covered: target by bookmark_id, update only supplied fields, one bookmark. However, with a 10-parameter schema and 0% description coverage, a bit more detail on null-clearing and parameter interactions would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must supply the key semantics; it does supply the crucial 'only supplied fields' rule, which clarifies why optional defaults don't mean all fields are set. Individual parameter names are mostly self-explanatory, but there is no explanation of ambiguous values like explicit null versus omission or what reparse_metadata does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a clear resource ('bookmark') and a precise scope: only the fields the caller supplies, and only one bookmark. This differentiates it from create_bookmark, get_bookmark, and search_bookmarks without needing the parameter schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording clearly situates the tool as the modification path for an existing bookmark, versus listing/searching/getting or creating. It does not name an alternative explicitly or state exclusions, but the partial-update phrasing gives the agent the relevant condition for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_bookmarkget_bookmarklist_collectionssearch_bookmarksupdate_bookmarkScored across 5 tools
Each tool targets a clearly distinct resource and action: collections are listed, while bookmarks are searched, fetched, created, or updated. There is no meaningful overlap between the tool purposes.
All tool names follow a consistent verb_noun snake_case pattern: list_collections, search_bookmarks, get_bookmark, create_bookmark, update_bookmark. The naming convention is uniform and predictable.
Five tools is a well-scoped size for a Raindrop.io MCP server, covering the main read and write operations without unnecessary sprawl. Each tool serves a distinct and valuable purpose.
The server covers listing collections and the main bookmark read/create/update operations, but notably lacks a delete_bookmark tool. Collection management is also limited to listing, with no way to create, update, or delete collections.
Save, search and organize bookmarks, highlights, feeds and knowledge cards in a Linkflare library.
Search everything you save: YouTube, articles, podcasts, PDFs, Notion, Obsidian. API key or OAuth.
Search, label, and manage your X (Twitter) bookmarks from any MCP client via Tweetsmash
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
