This server lets AI tools search, read, and manage Raindrop.io bookmarks through a small set of MCP tools.
List collections – view root and nested collections with bookmark counts and parent IDs.
Search or list bookmarks – use Raindrop.io search syntax, pagination, sorting, per-page limits, and collection filtering; results are compact summaries.
Get bookmark details – retrieve a single bookmark by ID with useful fields like title, link, tags, note, excerpt, cover, domain, and timestamps.
Create bookmarks – add a bookmark with optional title, tags, note, cover, excerpt, collection, importance, and metadata parsing.
Update bookmarks – modify only the supplied fields on one bookmark, optionally reparse metadata, and receive a compact confirmation of updated fields.
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 local Python MCP server I built to search and manage my Raindrop.io bookmarks from AI tools without exposing more account functionality than necessary.
I wanted the interface to stay deliberately small and auditable: a handful of explicit read/write tools, credentials kept outside the repository, and tests that never touch a real account.
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
Small, explicit tool surface: each operation has a clear purpose and read/write boundary.
Official REST API: the server talks directly to Raindrop.io rather than adding another integration layer.
Credentials via environment only: tokens stay outside the repository and tool arguments.
No implicit reads after writes: mutations return compact acknowledgements without making a second API request.
Fake transports in tests: the test suite never touches a real account.
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 listed read tools are approved automatically; create and update still require write approval.
.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.
Omit query to list bookmarks, or provide Raindrop.io's native search syntax.
Searches default to relevance; listings default to newest first.
Search results are compact summaries; use get_bookmark for full detail.
Write tools do not perform implicit follow-up reads and return compact acknowledgements instead of full API responses.
MCP tool annotations describe read and mutation behavior, but are hints rather than access controls.
See Tool behavior for pagination, collection semantics, request mappings, and response shapes.
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 tags with bookmark counts; collection_id 0 lists all tags.
A nonzero ID scopes the request to that collection. No child collections are fetched separately. The top-level count is the number of tags, not the number of bookmarks.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | 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 Ben, and the description adds meaningful behavior beyond that: the top-level count is tags, not bookmarks, and no child collections are fetched. This helps avoid misinterpretation of the response shape and scope.
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 short, front-loaded, and every sentence adds distinct information. There is no filler, and the most important scoping rule appears first.
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 one-parameter read-only list tool, the description covers the meaning of the parameter, the scope behavior, and the semantics of the returned count. An output schema exists for return values, so the description does not need to detail the full response structure.
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%, but the description fully compensates for the single parameter. It explains both the default sentinel value (0 means all tags) and the nonzero behavior (scope to that collection), which is exactly what an agent needs.
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 ('List tags with bookmark counts') and immediately signals the key behavioral variation (collection_id 0 lists all tags). It clearly distinguishes itself from sibling tools like list_collections by focusing on tags, counts, and collection scoping.
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?
It explicitly explains how to use the collection_id parameter: 0 means all tags, nonzero scopes to a collection. It also clarifies that child collections are not fetched separately. It does not explicitly mention when to prefer this over list_collections, but the scoping guidance is clear and actionable.
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.2list_tagsv0.1.0create_bookmarkget_bookmarklist_collectionssearch_bookmarksupdate_bookmarkScored across 6 tools
Each tool maps to a distinct resource-action pair: tags, collections, and bookmarks are cleanly separated, and get_bookmark is clearly different from search_bookmarks. No two tools appear to do the same thing.
All tool names follow the same lowercase verb_noun pattern: list, create, get, search, update. This is a predictable and consistent convention across the entire set.
Six tools is well-scoped for a Raindrop.io integration covering bookmarks, collections, and tags. Each tool has a clear purpose and the set is not bloated or overly thin.
Bookmark reading, creation, updating, and searching are covered, but there is no delete_bookmark, which is a notable lifecycle gap. Collections and tags are read-only, so collection/tag management operations are missing, though this may be intentional for a read-focused MCP server.
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.
