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.io MCP Server save this link to my machine learning collection"
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.
Raindrop.io is an all-in-one bookmark manager. This MCP server integration lets you manage your bookmarks programmatically—add, search, and organize your favorite links right from your LLM apps.
Related MCP server: Raindrop.io MCP Server
Add a bookmark (with tags, description, collection)
Get latest bookmarks
Search bookmarks by tag
Search bookmarks by keyword/text
Python 3.11
UV package manager
curl -LsSf https://astral.sh/uv/install.sh | sh
uv activate && uv installGrab an API token from Raindrop.io Developer Portal
Add the following to your MCP config:
{
"mcpServers": {
"Raindrop": {
"command": "uv",
"args": [
"--directory",
"<location to project clone>",
"run",
"raindrop.py"
],
"env": {
"RAINDROP_TOKEN": "<your_raindrop_token>"
}
}
}
}Restart your LLM app (Claude, Cursor, etc.)
Install automatically for Claude Desktop:
npx -y @smithery/cli install @sachin-philip/raindrop-io-mcp --client claudeAdd a bookmark (with tags, description, collection)
Get latest bookmarks
Search bookmarks by tag
Search bookmarks by keyword/text
MIT
Built by Sachin Philip
Add a new bookmark to Raindrop.io
Args:
url: The URL to bookmark (required)
title: Title for the bookmark (optional, will be extracted from URL if not provided)
description: Description/excerpt for the bookmark (optional)
tags: List of tags to apply to the bookmark (optional)
collection_id: ID of the collection to add the bookmark to (default: 0 for Unsorted)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| title | No | ||
| description | No | ||
| tags | No | ||
| collection_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes parameters but omits important behavioral traits like error handling, duplicate handling, rate limits, or idempotency.
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?
Efficient docstring format with clear one-line summary followed by structured Args list. No unnecessary words.
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?
Covers parameter semantics well but lacks behavioral context (return value, errors, edge cases) and no output schema to supplement. Adequate but not complete.
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?
With 0% schema coverage, description fully compensates by explaining each parameter's purpose, optionality, and default behavior (e.g., title extracted from URL if not provided, collection_id default 0).
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?
Clearly states verb 'Add' and resource 'bookmark' with platform 'Raindrop.io'. Distinct from sibling tools which are for searching or getting feed.
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?
No explicit when-to-use or when-not-to-use guidance. Usage is implied by the action name, but lacks direct comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest bookmarks from Raindrop.io feed.
Args:
count: Number of bookmarks to fetch (default: 10)
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation through 'Get', but does not explicitly state it is non-destructive or mention any permissions or side effects. Annotations are absent, so more explicit transparency would be beneficial.
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 very concise with one sentence and a structured parameter list. No unnecessary words, but it could include a bit more context without being verbose.
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 no output schema, the description does not explain the return format or error cases. It covers the basic purpose and parameter but lacks completeness for a tool that returns data.
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?
The description explains the 'count' parameter as 'Number of bookmarks to fetch' and notes the default value, adding value beyond the schema which only defines type and default. Since there is only one parameter, this coverage is good.
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 clearly states 'Get latest bookmarks from Raindrop.io feed.' The verb 'Get' and resource 'latest bookmarks' are specific, and it is distinct from siblings like add_bookmark or search_bookmarks.
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?
No guidance on when to use this tool vs alternatives. It does not mention when not to use it, or provide context for choosing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for bookmarks by keyword/text in Raindrop.io with optional date range filtering
Args:
query: The search term to look for in bookmarks (required)
collection_id: ID of the collection to search in (default: 0 for all collections)
count: Maximum number of bookmarks to return (default: 10)
from_date: Start date in YYYY-MM-DD format (optional)
to_date: End date in YYYY-MM-DD format (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| collection_id | No | ||
| count | No | ||
| from_date | No | ||
| to_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions defaults for collection_id and count and date format, but does not cover pagination, ordering, or behavior when no results are found.
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 structured with an Args block but is somewhat verbose. It could be more concise while retaining clarity.
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?
No output schema is provided, and the description does not hint at the return format (e.g., list of bookmark objects). Missing information about ordering or result structure makes it incomplete for a search tool.
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 adds significant value by explaining each parameter's purpose, defaults, and date format. It compensates well for the lacking 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 clearly states the tool searches for bookmarks by keyword/text with optional date range filtering. It specifies the resource (bookmarks) and action (search), distinguishing it from siblings like search_by_tag which searches by tag.
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 implies usage for keyword/text search but does not explicitly state when to use this tool versus alternatives like search_by_tag or add_bookmark. No when-not or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for bookmarks with a specific tag in Raindrop.io with optional date range filtering
Args:
tag: The tag to search for (required)
collection_id: ID of the collection to search in (default: 0 for all collections)
count: Maximum number of bookmarks to return (default: 10)
from_date: Start date in YYYY-MM-DD format (optional)
to_date: End date in YYYY-MM-DD format (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | ||
| collection_id | No | ||
| count | No | ||
| from_date | No | ||
| to_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It describes parameters but does not disclose whether the tool is read-only, destructive, or has rate limits. The return behavior is not mentioned.
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 concise with a clear header followed by a bulleted list of arguments. No unnecessary words or repetition.
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?
Input parameters are adequately described with defaults and format hints, but the absence of output schema means return values are not explained. Adequate for a 5-parameter tool with no nested objects.
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?
With 0% schema coverage, the description adds some value by clarifying defaults and date formats (e.g., 'YYYY-MM-DD'), but does not provide deep meaning beyond the schema for all 5 parameters.
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 clearly states the tool searches for bookmarks by tag with optional date range filtering, which is a specific verb-resource combination that distinguishes it from sibling tools like 'search_bookmarks'.
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?
No guidance on when to use this tool versus alternatives (e.g., 'search_bookmarks' for full-text search). It does not specify exclusions or prerequisites.
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.0add_bookmarkget_latest_feedsearch_bookmarkssearch_by_tagScored across 4 tools
Each tool has a distinct purpose: adding a bookmark, retrieving recent feed, searching by keyword, and searching by tag. No overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (add_bookmark, get_latest_feed, search_bookmarks, search_by_tag), making them predictable and easy to understand.
With 4 tools, the server is scoped to essential bookmarking operations: add, feed, and search. This is slightly minimal but still reasonable for a basic integration.
The tool set lacks update/delete functionality and any way to list bookmarks beyond the feed or search. There is no tool for managing collections, leaving notable gaps for full CRUD operations.
Save, search and organize bookmarks, highlights, feeds and knowledge cards in a Linkflare library.
Save, search and shorten links from chat: bookmarks, short links, QR codes, UTM links, invoices.
Search everything you save: YouTube, articles, podcasts, PDFs, Notion, Obsidian. API key or OAuth.
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
