Rainkeeper is an MCP server that gives Claude natural-language control over your Raindrop.io bookmark library, covering collections, bookmarks, bulk operations, search, and tags — with full support for free accounts.
Collections
List all collections (root and sub-collections) with IDs, titles, parent IDs, and counts
Get details of a single collection by ID
Create collections, including nested sub-collections via parent_id
Update collections — rename, recolor, or toggle public visibility
Delete collections (contents move to Unsorted automatically)
Bookmarks
List bookmarks in any collection (0 = All, -1 = Unsorted), with pagination and sorting
Get a single bookmark by ID (full detail: tags, note, type, domain)
Create a new bookmark with optional title, tags, note, and target collection
Update a bookmark — change title, tags, note, importance, or collection
Move a bookmark explicitly to a different collection
Delete a bookmark permanently
Bulk Operations
Move multiple bookmarks to a target collection in one call
Apply tags to multiple bookmarks (merges with existing tags)
Mark multiple bookmarks as important (star/unstar)
Permanently delete multiple bookmarks
Search
Search across your entire library or within a specific collection using Raindrop's full search syntax: keywords, phrases ("machine learning"), tags (#ai), types (type:article), exclusions (-draft), domains (site:github.com), unsorted (collection:unsorted), and starred (important:true)
Tags
List all tags across your library, optionally scoped to a specific collection
Rename a tag everywhere it appears
Delete one or more tags from all bookmarks
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., "@rainkeeper list my collections"
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.
· · · · · · · · · · · · · · · ·
· · · · · · · · · · · · · ·
____ _ ___ _ _ _ _______ _____ _____ ____ _____ ____
| _ \ / \ |_ _| \ | | |/ / ____| ____| ___| _ \| ____| __ \
| |_) | / _ \ | || \| | ' /| _| | _| | |_ | |_) | _| | /
| _ < / ___ \ | || |\ | . \| |___| |___| _| | __/| |___| _ \
|_| \_\/_/ \_\___|_| \_|_|\_\_____|_____|_| |_| |_____|_| \_\
· · · · · · · · · · · · · ·
· · · · · · · · · · · · · · · ·The Raindrop.io MCP Server that works on free accounts — and actually moves bookmarks.
Raindrop.io is the bookmark manager that makes the web collectible. Save anything — articles, videos, PDFs, images, links — organise it into collections and sub-collections, tag it, annotate it, and surface it exactly when you need it. It runs on every platform, syncs everywhere, and has a free tier that covers everything most people ever need.
If you've ever lost a link, abandoned browser bookmarks, or wished your read-later queue could talk back — Raindrop is the answer.
Rainkeeper connects Raindrop to Claude, giving you natural-language control over your entire library.
Related MCP server: Raindrop.io MCP Server
Two problems with the existing MCP options:
The official Raindrop.io MCP server requires a Pro subscription (~$3/month). If you're on the free tier — which covers the vast majority of Raindrop's feature set — you cannot use it.
The community alternative (adeze/raindrop-mcp) has a silent critical bug: collection moves do nothing. Ask Claude to file a bookmark into a collection, and the API call returns 200 OK — while the bookmark sits exactly where it was. The root cause is a malformed request body that the Raindrop API silently ignores. The same bug breaks all bulk move operations.
Rainkeeper fixes both.
Rainkeeper | Official MCP | Community MCP | |
Free account | ✅ | ❌ Pro only | ✅ |
Collection moves work | ✅ | ✅ | ❌ Silent fail |
Sub-collection support | ✅ | — | ❌ |
Bulk operations | ✅ | — | ✅ (broken) |
Self-hostable | ✅ | ✅ | ✅ |
Open source (MIT) | ✅ | — | ✅ |
The Raindrop.io REST API uses a nested object for all collection references. Sending a flat integer is accepted without error — and silently ignored.
// ✅ Correct — what Rainkeeper sends
PUT /raindrop/123
{"collection": {"$id": 456}}
// ❌ Silently ignored — what the community MCP sends
PUT /raindrop/123
{"collectionId": 456}The same applies to bulk operations:
// ✅ Correct
PUT /raindrops/0
{"ids": [111, 222], "collection": {"$id": 456}}
// ❌ Returns 404 or silently fails
PUT /raindrops/0
{"ids": [111, 222], "collectionId": 456}RaindropClient enforces the correct format at the HTTP layer. Tools never pass raw integer IDs to the API. One rule, one place, always correct.
Raindrop.io → Settings → Integrations → For Developers → create an app → copy the Test token. Free accounts included. Takes 30 seconds.
git clone https://github.com/simonives/rainkeeper.git
cd rainkeeper
pip install -e . # or: uv pip install -e .cp .env.example .env
# Open .env — set RAINDROP_ACCESS_TOKEN=your_token_hereAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"rainkeeper": {
"command": "python",
"args": ["-m", "rainkeeper.server"],
"cwd": "/absolute/path/to/rainkeeper",
"env": {
"RAINDROP_ACCESS_TOKEN": "your_token_here"
}
}
}
}Restart Claude Desktop after saving.
claude mcp add rainkeeper -- python -m rainkeeper.serverMake sure your .env is in the rainkeeper directory and contains your token.
Ask Claude: "List my Raindrop collections."
You should see your collections within a few seconds. If you get an auth error, verify the token in your config matches what's in Raindrop Settings → Integrations.
Rainkeeper exposes 17 tools across five domains. Claude selects the right tool automatically — docstrings are tuned for tool selection accuracy.
Start every session with
list_collections. You need collection IDs to move or file bookmarks, and Raindrop doesn't use predictable names as identifiers.
Tool | What it does |
| All collections and sub-collections — id, title, parent_id, count |
| Single collection detail |
| New collection; pass |
| Rename, recolour, or toggle public visibility |
| Delete a collection — contents move to Unsorted |
Tool | Key parameters | Notes |
|
|
|
|
| Full detail: tags, note, type, domain |
|
| Saves to Unsorted by default |
|
| Pass |
|
| Explicit move — better tool selection than update |
|
| Permanent |
Tool | What it does |
| Move a list of bookmark IDs to a target collection |
| Apply tags to a list of bookmarks (merges with existing) |
| Star or unstar a list of bookmarks |
| Permanently delete a list of bookmarks |
Tool | Notes |
| Searches all bookmarks by default ( |
Search syntax:
Syntax | Example | Finds |
Word |
| Bookmarks containing "python" |
Phrase |
| Exact phrase match |
Tag |
| Bookmarks tagged "ai" |
Type |
| Articles only ( |
Exclude |
| Excludes the word "draft" |
Domain |
| From a specific domain |
Untagged |
| Bookmarks with no tags |
Unsorted |
| Items in Unsorted |
Starred |
| Starred / important bookmarks |
Tool | What it does |
| All tags across your library; pass |
| Rename a tag everywhere it appears |
| Remove one or more tags from all bookmarks |
Rainkeeper is built for inbox-zero sweeps: work through Unsorted, tag and file everything, leave nothing behind.
"List everything in my Unsorted collection and suggest a collection for each."
"Move all bookmarks tagged #read-later to my Reading collection."
"Search for everything tagged #ai from the last 30 days and list titles and URLs."
"Rename the tag 'ai-tools' to 'ai' across my whole library."
"File the 20 most recent bookmarks into the right collections based on their titles."
"Delete everything in Unsorted older than 6 months."rainkeeper/
├── src/
│ └── rainkeeper/
│ ├── server.py FastMCP app · registers all tools
│ ├── client.py RaindropClient · all HTTP lives here
│ ├── config.py RAINDROP_ACCESS_TOKEN · BASE_URL · headers
│ └── tools/
│ ├── collections.py 5 tools — list · get · create · update · delete
│ ├── raindrops.py 6 tools — list · get · create · update · move · delete
│ ├── bulk.py 4 tools — move · tag · star · delete (batch)
│ ├── search.py 1 tool — full-text + Raindrop syntax
│ └── tags.py 3 tools — list · rename · delete
├── .env.example token template — copy to .env, never commit .env
├── pyproject.toml installable package · rainkeeper CLI entrypoint
└── README.mdDesign rule: RaindropClient owns all HTTP. Tools are thin wrappers — no httpx in tool files. The API mapping (including the collection move fix) is enforced in one place and testable independently of the MCP layer.
The following Raindrop.io API capabilities are not yet exposed. Open a feature request if any matter to your workflow, or start an idea in Discussions.
Highlights — create and read highlights within a bookmark
User profile — GET /user (handy for verifying auth is working)
Imports / exports — bulk HTML bookmark import, export to file
Sharing — shared collection management
OAuth 2.0 — multi-user auth; currently personal test token only
Rainkeeper is maintained by @simonives. See CONTRIBUTING.md for how to raise bugs, propose features, and fork the project.
MIT — see LICENSE.
Permanently delete multiple bookmarks. ids must be non-empty.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Permanently delete' indicating irreversibility, which is a behavioral cue. However, with no annotations provided, it fails to disclose other important traits such as authorization requirements, partial failure handling, rate limits, or side effects like cascading deletions.
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?
Two sentences with no waste. The action is front-loaded, and a critical constraint (non-empty ids) follows immediately. Minor improvement could be more specificity on the resource type.
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 presence of an output schema (not shown), return values are covered. However, the description lacks usage guidelines, behavioral transparency, and full parameter semantics, leaving the agent underinformed for a destructive 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?
The description adds value by specifying that 'ids must be non-empty', which is not evident from the schema. However, it provides no explanation for 'collection_id', leaving it ambiguous. Since schema coverage is 0%, the description partially compensates but is incomplete.
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 action (permanently delete) and the resource (multiple bookmarks/raindrops). It effectively distinguishes from the sibling 'delete_raindrop' by implying multiplicity. However, it could be more explicit that it operates on bookmarks within a specific collection.
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 like 'delete_raindrop' for single deletions, or other bulk operations. There is no mention of prerequisites (e.g., requiring collection_id) or context for batch behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag multiple bookmarks as important (starred). ids must be non-empty.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| important | No | ||
| collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It only states the action and a constraint ('ids must be non-empty'), but omits behavioral details like idempotency, authentication needs, side effects, or error handling.
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 two sentences, no wasted words, and the key action is front-loaded. Although sparse, it achieves maximum efficiency for its length.
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 3 parameters (2 required), no annotations, and an unknown output schema, the description covers only the core purpose and one constraint. It lacks parameter explanations, behavioral notes, and error handling, making it incomplete for complex use.
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 explain parameters. It only adds a constraint on 'ids' (non-empty) but does not explain 'important' (default true) or 'collection_id'. This is insufficient for an agent to use parameters correctly.
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 action ('Flag multiple bookmarks as important (starred)'), specifying the verb and resource. It distinguishes from siblings like bulk_delete, bulk_move, and bulk_tag by focusing on marking importance.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusion criteria or preferred scenarios, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move multiple bookmarks to a target collection. ids must be non-empty and all from source_collection_id — ids from other collections are silently skipped by the API.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| source_collection_id | Yes | ||
| target_collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the silent skipping behavior, which is helpful. However, it omits other behavioral details like success response, partial failure handling, or atomicity.
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?
Two concise sentences that front-load the core purpose and immediately follow with critical constraint. 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?
With an output schema likely covering return values, the description is reasonably complete for a bulk operation. It could mention prerequisites or failure scenarios, but the constraint and behavioral note add sufficient context.
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?
Despite 0% schema description coverage, the description adds meaning beyond the schema by imposing constraints ('non-empty', 'all from source_collection_id') and explaining the silent skip behavior for ids from other collections.
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 action ('Move multiple bookmarks') and resource ('to a target collection'). It distinguishes from sibling tools like 'move_raindrop' (single) and 'bulk_delete_raindrops' (different action).
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 provides important constraints ('ids must be non-empty and all from source_collection_id') and a behavioral caveat ('ids from other collections are silently skipped'). However, it does not explicitly compare to alternative tools like 'move_raindrop' for single moves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply tags to multiple bookmarks. Merges with existing tags. WARNING: passing tags=[] will remove all tags from the targeted bookmarks.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| tags | Yes | ||
| collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description adds key behavioral info: merges with existing tags and warns that passing tags=[] removes all tags. This mitigates misinterpretation. However, it could mention if the operation is idempotent or whether it returns the updated bookmarks.
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?
Concise: two sentences and a warning. Front-loaded with purpose. The warning is appropriately prominent. Could be slightly tighter, but overall efficient.
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 tool has an output schema and three required params, the description covers the core behavior but omits return value details and param semantics. Sibling tools are numerous, but the description suffices for basic usage. More context around expected output would improve completeness.
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 has 0% description coverage, and the description adds minimal parameter context beyond the param names. The warning about tags=[] partially clarifies that parameter's effect, but ids and collection_id are not explained. For a schema with three required fields, more parameter-level detail would be beneficial.
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?
Description clearly states the action 'Apply tags' to the resource 'multiple bookmarks' and specifies behavioral nuance 'Merges with existing tags'. This distinguishes it from siblings like bulk_delete_raindrops and warns against a dangerous use case.
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?
Usage is implied (apply tags to multiple bookmarks), but no explicit guidance on when to use this tool versus others like bulk_mark_important or search_raindrops. No alternative recommendations or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new collection. Pass parent_id to create a sub-collection.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | ||
| title | Yes | ||
| public | No | ||
| parent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral insight is that passing parent_id creates a sub-collection. Missing details include: whether it replaces existing collections, requires specific permissions, auto-generates any fields, or is idempotent. Without annotations, the description fails to adequately disclose behavioral traits.
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 at two sentences, but it omits critical information. It earns points for brevity but loses for under-specification – not every sentence is maximally informative.
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 complexity (4 parameters, 1 required) and no behavioral annotations, the description is incomplete. It fails to explain return values despite an output schema being present, and does not cover the full parameter semantics. A more complete description would at least list parameters and their effects.
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 description coverage, the description adds no meaning to three out of four parameters (title, color, public). It only hints at parent_id. The agent must infer the role of title as required, and has no semantic insight into color or public.
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 action (create a new collection) and hints at the ability to create sub-collections via parent_id, distinguishing it from tools like update_collection or delete_collection. However, it lacks specificity about what constitutes a 'collection' in the domain.
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 is provided on when to use this tool versus alternatives (e.g., create_raindrop, update_collection). There is no mention of prerequisites, limitations, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a new bookmark. collection_id -1 = Unsorted. Tags is a list of strings. Pass title='' to explicitly clear the auto-detected title.
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | ||
| note | No | ||
| tags | No | ||
| title | No | ||
| important | No | ||
| collection_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: special value for collection_id (-1 for Unsorted), tags format, and clearing auto-detected title. This adds value beyond the schema, though it doesn't cover all traits like authentication or rate limits.
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 sentences, each adding specific value: purpose, parameter hints, and a practical tip. No wasted words; 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?
Given 6 parameters and no schema descriptions or annotations, the description partially explains parameters (3 out of 6) and behavior. Output schema exists but isn't referenced. Missing details on note and important could lead to incomplete understanding.
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 description must compensate. It explains collection_id, tags, and title (3 of 6 parameters), but omits details for link, note, and important. Provides useful context but not comprehensive.
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?
Description clearly states 'Save a new bookmark' – a specific verb and resource. It distinguishes from sibling tools like update_raindrop, delete_raindrop, and bulk operations, making its purpose unambiguous.
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 creating bookmarks, but does not explicitly state when not to use it (e.g., for updates) or compare to alternatives. However, given the context of a create tool and sibling names, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a collection. Contents move to Unsorted.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the key side effect of moving contents to Unsorted, which is beyond the obvious deletion. However, it does not mention recovery options, permissions, or whether the operation is reversible. Given no annotations, the description carries full burden but is partially adequate.
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?
Extremely concise: one sentence delivering the essential purpose and side effect with no extraneous words. Front-loaded and efficient.
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 low-complexity tool with one parameter and an output schema, the description covers the core action and side effect but omits details on the return value, prerequisites, or error states. It is functional but not comprehensive.
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 description coverage, the description should add meaning to the single parameter (collection_id) but only alludes to it implicitly via 'a collection'. No additional type, format, or usage details are provided, leaving the schema to carry the full weight.
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 action ('Delete a collection') and the primary side effect ('Contents move to Unsorted'), distinguishing it from siblings like delete_raindrop or bulk operations.
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 guidance on when to use this tool versus alternatives (e.g., update_collection or delete_raindrop). The description is minimal and leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a bookmark permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| raindrop_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the action is 'permanent', which is a key behavioral trait. However, no annotations are provided, and other aspects like irreversibility's implications or safety are not disclosed.
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 sentence with no unnecessary words, making it concise and front-loaded. It is appropriately sized for a simple tool.
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?
While the tool is simple and an output schema exists, the description lacks mention of success/failure conditions or error handling. It is adequate but minimal for a destructive action.
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 tool description adds no meaning to the 'raindrop_id' parameter beyond what is already in the input schema. The parameter is not explained in the description.
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 action ('Delete') and the resource ('a bookmark'), making it specific and distinct from siblings like 'bulk_delete_raindrops' which implies multiple deletions.
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 guidance on when to use this tool versus alternatives (e.g., bulk_delete_raindrops) or prerequisites. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one or more tags from all bookmarks.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Delete one or more tags from all bookmarks' but does not disclose what happens to the tags themselves (e.g., are they removed from bookmarks but tag definition persists?) or any authorization or rate-limiting considerations.
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 sentence, very concise and front-loaded. However, it sacrifices necessary detail for brevity. Still, it is well-structured for a simple tool.
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 tool with one parameter and an existing output schema (which need not describe return values), the description is minimally adequate. It states the core operation but lacks contextual details like side effects or error conditions.
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 only parameter 'tags' is an array of strings. Schema description coverage is 0%. The description adds 'one or more tags' but does not clarify constraints like case sensitivity, whether tags must exist, or format expectations. It adds minimal value beyond 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 clearly states the action (delete), the resource (tags), and the scope (all bookmarks). It distinguishes itself from siblings like rename_tag and bulk_delete_raindrops by specifying that it operates on tags and affects all 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 is provided on when to use this tool versus alternatives such as rename_tag or bulk_tag_raindrops. There is no mention of prerequisites, when not to use, or the implications of deleting tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a single collection by id.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a non-destructive read operation but does not mention auth, rate limits, or error cases.
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?
Single sentence, 9 words, front-loaded with verb and resource. No redundant information.
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 presence of an output schema, the description does not need to explain return values. However, it lacks context about error handling, prerequisites, or comparison with sibling tools.
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 description coverage and only one parameter, the description adds minimal value beyond 'by id'. It does not explain what the id represents or any constraints beyond type integer.
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 verb 'get', resource 'collection', and specifies it returns details for a single collection by id, distinguishing it from siblings like list_collections.
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 when a specific collection id is known but does not explicitly contrast with siblings like list_collections (for multiple) or update_collection (for modification).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single bookmark by id.
| Name | Required | Description | Default |
|---|---|---|---|
| raindrop_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose read-only nature, idempotency, error behavior, or any side effects. The phrase 'Get' implies a read operation but is not explicit.
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, front-loaded sentence that conveys the core purpose efficiently. It could include minimal elaboration without becoming 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?
For a simple read tool with one parameter and an output schema, the description is minimal but covers the basic action. However, it lacks information on authentication, rate limits, and error responses, which may be needed for confident 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%, so the description must compensate. It mentions 'by id' which maps to the raindrop_id parameter, but adds no details about format, constraints, or default values beyond 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 clearly states the action ('Get'), the resource ('a single bookmark'), and the method ('by id'). It effectively distinguishes from sibling tools like list_raindrops and search_raindrops.
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 is provided on when to use this tool versus alternatives such as list_raindrops or search_raindrops. The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Raindrop.io collections (root and sub-collections), with id, title, and parent_id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses returned fields but does not state that this is a read-only operation, nor mentions pagination, rate limits, or other behavioral traits. For a list tool with no parameters, some transparency on completeness or ordering would be helpful.
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?
Single sentence, efficiently captures action and output. No wasted words, front-loaded with the verb and resource.
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 list tool with no parameters and a likely straightforward output, the description is nearly complete. It would benefit from mentioning that it returns all collections without pagination or filtering, but overall adequate.
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?
No input parameters exist, and schema coverage is 100% (trivially). The description does not add to parameter semantics, but is not required to. Baseline 3 is appropriate.
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 the verb 'List', resource 'all Raindrop.io collections (root and sub-collections)', and specifies returned fields (id, title, parent_id). Distinguishes from sibling tools like 'get_collection' (single) and mutation tools.
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 use for listing all collections, but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bookmarks in a collection. collection_id 0 = All, -1 = Unsorted. sort: -created, title, -title, domain. Maximum per_page is 50.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | ||
| per_page | No | ||
| collection_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses maximum per_page and allowed sort values, but omits pagination behavior, authentication requirements, and read-only nature.
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?
Two concise sentences front-loading the purpose and key parameter details with zero waste.
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 most parameters and constraints. Lacks pagination behavior details for the page parameter, but output schema presumably covers return 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 description coverage is 0%, but description explains collection_id special values, sort options, and per_page limit. Missing explanation for the page parameter (default 0 vs. 1-based indexing).
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 'List bookmarks in a collection' with specific verb and resource. Provides special values for collection_id and sort options, distinguishing it from siblings like search_raindrops.
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?
Gives explicit guidance on collection_id special values and sort options. Does not explicitly mention when not to use this tool or 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.
List all tags. Pass collection_id to scope to a specific collection.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It implies a read operation but does not disclose side effects, pagination, or limitations. Adequate for a simple list tool.
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?
Two sentences, no fluff, front-loaded with purpose and optional parameter usage.
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?
With low complexity, one parameter, and an output schema present, the description covers all needed aspects 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%, but description explains the purpose of collection_id: to scope to a specific collection. This adds value beyond the schema alone.
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 verb 'List' and the resource 'tags', with optional scoping by collection. It is distinct from sibling tools like list_raindrops or list_collections.
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 tells when to use: list all tags, and how to scope using collection_id. However, it does not explicitly mention when not to use or alternatives like searching tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a single bookmark to a different collection. Explicit tool for clarity.
| Name | Required | Description | Default |
|---|---|---|---|
| raindrop_id | Yes | ||
| target_collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the basic action without disclosing any behavioral traits like idempotency, error handling, or side effects.
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, but it is efficient and front-loaded; however, it may be too brief to convey necessary details.
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 tool has two simple parameters and an output schema, but the description lacks context on return values, error conditions, or prerequisites, making it incomplete for a thorough understanding.
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% and the description adds no meaning to the parameters ('raindrop_id', 'target_collection_id') beyond their names.
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 action ('move'), resource ('bookmark'), and target ('collection'), and distinguishes from bulk counterparts with 'single bookmark' and 'Explicit tool for clarity'.
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 a single-item use case, and the sibling tool 'bulk_move_raindrops' provides contrast, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a tag across all bookmarks.
| Name | Required | Description | Default |
|---|---|---|---|
| new_tag | Yes | ||
| old_tag | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the scope 'across all bookmarks' but fails to disclose critical behaviors such as whether renaming merges with an existing new tag, or if the operation is reversible. Without annotations, this minimal disclosure is insufficient.
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 concise sentence, but it sacrifices necessary detail. While front-loaded, it is oversimplified for a rename operation affecting all bookmarks.
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 mutation tool with no annotations and simple string parameters, the description is incomplete. It does not explain behavior when new_tag already exists or whether the operation is atomic, leaving an agent uncertain about consequences.
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 has 0% parameter descriptions and the tool description provides no additional meaning for old_tag or new_tag (e.g., format, case sensitivity, existence requirements). The description only implies their roles, which is inadequate for proper parameter understanding.
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 'Rename a tag across all bookmarks' clearly states the action (rename) and resource (tag), and distinguishes from sibling tools like delete_tags or bulk_tag_raindrops. However, it could be more explicit about the effect on all bookmarks having the old 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?
No guidance is provided on when to use this tool versus alternatives (e.g., delete_tags and bulk_tag_raindrops). The agent receives no information about prerequisites or contraindications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bookmarks using Raindrop search syntax. collection_id 0 = search all. Supports #tag, word, "phrase", type:article, etc. Maximum per_page is 50.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes | ||
| per_page | No | ||
| collection_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It states max per_page 50 and supported syntax, but does not disclose read-only nature, authentication needs, rate limits, or pagination behavior beyond per_page. Could be more informative.
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?
Two sentences, no filler, front-loaded with purpose. Every sentence adds 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?
Given 4 simple parameters and existence of an output schema, the description covers main usage points: search syntax, special collection_id, per_page limit. Missing details on pagination and sorting, but adequate 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 descriptions cover 0% of parameters, so description must compensate. It adds meaning to collection_id (0 = search all) and per_page (max 50), but does not describe page or query parameters fully. Query is required but only generally described as 'search syntax'.
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 'Search bookmarks using Raindrop search syntax', specifying the verb and resource. It distinguishes from sibling list_raindrops by emphasizing search syntax and including special collection_id 0 meaning search all.
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?
Provides context on when to use: when search syntax is needed. Includes special collection_id value and max per_page. Does not explicitly mention alternatives or when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a collection's title, visibility, or colour. color is a hex string e.g. '#ff0000'.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | ||
| title | No | ||
| public | No | ||
| collection_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations absent, so description carries full burden. Only states 'update' which implies a write operation, but no mention of side effects, permissions, reversibility, or error conditions. Output schema present but not referenced.
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?
Very concise single sentence, no redundant information. Front-loaded with key action and fields. Efficient use of 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?
Given 4 parameters, 1 required, and no annotations, the description is minimal. Lacks details on partial updates, error handling, or authorization. Output schema partially compensates, but overall incomplete for safe 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 description compensates partially. Provides example for 'color' hex string, but only lists 'title' and 'visibility' without additional constraints or formatting. No description for 'collection_id' despite being required.
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 it updates a collection's title, visibility, or colour. Distinguishes from sibling tools like create_collection and delete_collection. Minor mismatch: description says 'visibility' while schema uses 'public', but synonymous.
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 guidance on when to use this tool vs alternatives (e.g., create_collection, get_collection). Usage is implied by the verb 'update', but no context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a bookmark. Pass collection_id to move it — uses the correct nested API format.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| tags | No | ||
| title | No | ||
| important | No | ||
| raindrop_id | Yes | ||
| collection_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it only mentions API format. It fails to describe side effects, prerequisites, or mutation behavior.
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?
Extremely concise with one sentence and front-loaded main action, but the brevity sacrifices crucial information, making it less effective.
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?
Although an output schema exists, the description does not cover the full parameter set or provide enough context for correct usage, given the complexity of 6 parameters.
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 description coverage, the description should compensate but only mentions collection_id's role. No explanation for note, tags, title, or important 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 updates a bookmark and explicitly mentions moving by passing collection_id, distinguishing it from sibling tools like move_raindrop.
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?
Provides clear context on when to use the tool (updating and moving via collection_id) but lacks explicit exclusions or mention of alternatives like move_raindrop.
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.0bulk_delete_raindropsbulk_mark_importantbulk_move_raindropsbulk_tag_raindropscreate_collectioncreate_raindropdelete_collectiondelete_raindropdelete_tagsget_collectionget_raindroplist_collectionslist_raindropslist_tagsmove_raindroprename_tagsearch_raindropsupdate_collectionupdate_raindropScored across 19 tools
Tools are mostly distinct across resources (collections, raindrops, tags) and actions (create, delete, list, etc.). However, bulk operations and single operations (e.g., bulk_move_raindrops vs move_raindrop) have overlapping purposes, and bulk_mark_important could be considered a subset of update_raindrop.
All tools follow a consistent verb_noun pattern in snake_case, with optional prefixes like bulk_ or create_ indicating scope. There are no violations or mixed conventions.
19 tools cover the essential operations for a bookmark management API: CRUD, bulk operations, search, and tag management. This is neither too few nor too many for the domain.
The tool set covers most core functionalities: CRUD for collections and raindrops, tag management, search, and bulk actions. Missing advanced features like import/export or sharing, but the core workflow is complete.
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
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.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Bounded tools for rendering, extraction, RAG, enrichment, local discovery and review analysis.
