Raindrop.io

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources (bookmarks, collections, highlights, tags) and actions, with clear boundaries. However, some overlap exists between deleteTag and deleteTags, and between getHighlights and getHighlightsByCollection, which could cause minor confusion.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear and predictable naming (e.g., createBookmark, getBookmarks, updateCollection). All names use camelCase uniformly, making them easy to parse and understand.
Tool Count3/5
With 37 tools, the count is high and feels heavy for a bookmark management domain. While many tools cover specific operations, the number may overwhelm agents and could likely be consolidated or streamlined without losing functionality.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for bookmarks, collections, highlights, tags, and user operations. It includes advanced features like bulk operations, reminders, sharing, and import/export, leaving no obvious gaps for the domain.
Average 2.8/5 across 37 of 37 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on March 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get all tags' implies a read-only operation, but it doesn't specify if this requires authentication, returns paginated results, includes metadata like tag counts, or has rate limits. For a tool with zero annotation coverage, this leaves critical behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and efficient. However, it borders on under-specification—while not wasteful, it could benefit from slightly more detail to clarify scope or usage without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'tags' are in this system, what data is returned, or how it relates to sibling tools like those for bookmarks or collections. For a tool in a rich context with many siblings, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'collectionId' documented as 'Filter tags by collection'. The description 'Get all tags' implies no filtering by default, which aligns with the optional nature of the parameter. Since schema coverage is high, the baseline score is 3, as the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all tags' is a tautology that restates the tool name 'getTags' without adding meaningful specificity. It doesn't distinguish this tool from sibling tools like 'mergeTags' or 'renameTag' by explaining what 'tags' are in this context or what 'get' entails. While it uses a clear verb+resource pattern, it lacks differentiation from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mergeTags' or 'renameTag' for tag management, nor does it explain if this is for listing, filtering, or retrieving tag metadata. There's no context on prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create a new collection', implying a write operation, but doesn't mention permissions, side effects (e.g., if it affects other collections), or response format. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, which is efficient. However, it's arguably too brief, lacking necessary context for a creation tool, but it doesn't waste words or include irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like success conditions, error handling, or what the new collection entails, leaving the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters (title and isPublic). The description adds no additional meaning beyond implying creation, which the schema doesn't cover, but it doesn't explain parameter interactions or defaults, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create') and resource ('collection'), which is clear but minimal. It doesn't specify what a 'collection' is in this context or differentiate it from similar tools like 'mergeCollections' or 'shareCollection', making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'mergeCollections' or 'shareCollection'. The description lacks context about prerequisites, such as needing a title, or when creation is appropriate versus updating or sharing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a deletion but doesn't cover critical aspects like whether this requires specific permissions, if deletions are reversible, what happens to associated data, or any rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and efficient. However, it borders on under-specification given the tool's complexity, as it could benefit from slightly more detail to clarify scope or behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description is incomplete. It doesn't explain the deletion process, potential side effects, error conditions, or return values, leaving the agent with insufficient context to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'Bookmark ID' for 'id', 'Permanently delete (skip trash)' for 'permanent'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a bookmark' states the basic action (delete) and resource (bookmark), making the purpose understandable. However, it lacks specificity about scope (e.g., single vs. batch) and doesn't differentiate from sibling tools like 'batchDeleteBookmarks' or 'deleteCollection', leaving ambiguity about when to use this particular tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites, exclusions, or comparisons to siblings like 'batchDeleteBookmarks' for multiple deletions or 'emptyTrash' for cleanup, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention permissions required, whether deletion is permanent or reversible, effects on contained items, or error conditions. For a destructive operation, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action. However, it's arguably under-specified rather than efficiently informative, as it omits critical context for a destructive tool. Still, it wastes no words on redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address safety, return values, or error handling, leaving the agent with insufficient context to use it correctly. More detail is needed for such a high-stakes operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'id' documented as 'Collection ID'. The description adds no additional meaning beyond this, such as format examples or where to find the ID. Baseline 3 is appropriate since the schema adequately covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a collection' clearly states the action (delete) and target (collection), but it's vague about scope and doesn't distinguish from sibling tools like 'deleteBookmark', 'deleteHighlight', or 'emptyTrash'. It provides basic purpose but lacks specificity about what constitutes a collection or deletion consequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'emptyTrash' or 'removeEmptyCollections', nor are prerequisites or constraints mentioned. The description offers no context for selection among deletion-related tools, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'optional filtering' but doesn't explain key behaviors like pagination (implied by 'page' and 'perPage' parameters), rate limits, authentication needs, or what happens when no filters are applied. For a read operation with multiple parameters, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get bookmarks') and adds a qualifier ('with optional filtering'). There's no wasted text, making it appropriately concise. However, it could be more structured by explicitly stating it's for listing or retrieving multiple bookmarks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 6 parameters, the description is incomplete. It doesn't explain the tool's behavior (e.g., pagination, filtering logic), return values, or how it differs from siblings like 'searchBookmarks'. For a tool with this complexity and lack of structured data, the description should provide more context to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters with descriptions and enums for 'sort'. The description adds no additional meaning beyond implying filtering capabilities, which the schema already covers via parameters like 'search', 'tags', and 'collection'. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get bookmarks with optional filtering' clearly states the verb ('Get') and resource ('bookmarks'), and mentions optional filtering. However, it doesn't distinguish this tool from sibling tools like 'searchBookmarks' or 'getBookmark', leaving ambiguity about when to use each. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'searchBookmarks' and 'getBookmark' available, there's no indication of whether this tool is for listing all bookmarks, filtered searches, or other use cases. The mention of 'optional filtering' is vague and doesn't clarify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get user statistics' implies a read-only operation but doesn't specify authentication needs, rate limits, error conditions, or what the output looks like. For a tool with zero annotation coverage, this is inadequate behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, which is efficient and front-loaded. However, it's arguably too brief given the lack of other context, bordering on under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of user statistics (which could include various metrics), no annotations, and no output schema, the description is incomplete. It doesn't explain what statistics are returned, how they're formatted, or any behavioral nuances, making it insufficient for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'collectionId' documented as 'Collection ID for specific collection stats'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user statistics' clearly states the verb ('Get') and resource ('user statistics'), making the basic purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'getUserInfo' or specify what kind of statistics are retrieved, leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getUserInfo' or other sibling tools. There's no mention of prerequisites, context, or exclusions, leaving the agent with no usage direction beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create a new bookmark' implies a write operation but doesn't specify permissions required, whether it's idempotent, what happens on duplicate links, or the response format. For a mutation tool with zero annotation coverage, this is insufficient—it lacks critical behavioral details like 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Create a new bookmark' is front-loaded and appropriately sized for its purpose. It avoids unnecessary elaboration, making it easy to parse quickly without sacrificing clarity for its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions or idempotency, doesn't explain parameter interactions, and omits return values. For a creation tool in a system with many siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters (e.g., 'link' as URL, 'collectionId' as number). The description adds no meaning beyond this, not explaining relationships like how 'collectionId' relates to collections or what 'important' entails. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new bookmark' clearly states the action (create) and resource (bookmark), but it's vague about what constitutes a bookmark in this system and doesn't differentiate from sibling tools like 'createCollection' or 'createHighlight'. It provides basic purpose but lacks specificity about the bookmark's nature or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'updateBookmark', 'batchUpdateBookmarks', and 'searchBookmarks', the description doesn't indicate whether this is for initial creation only, whether it should be used instead of batch operations for single items, or any prerequisites. The absence of usage context leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete a highlight' implies a destructive mutation, but it doesn't specify if the deletion is permanent, reversible, requires specific permissions, has side effects (e.g., on associated bookmarks), or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Delete a highlight' is extremely concise—just three words—and front-loaded with the core action. There is no wasted language or unnecessary elaboration, making it efficient for quick comprehension. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive mutation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what a 'highlight' is in this context, how to obtain the ID, the deletion's permanence, or what to expect upon success. For a tool that permanently removes data, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Highlight ID'. The description adds no additional meaning beyond this, such as format examples (e.g., numeric ID from getHighlights) or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a highlight' clearly states the verb ('Delete') and resource ('a highlight'), making the basic purpose understandable. However, it doesn't distinguish this tool from other deletion tools like deleteBookmark, deleteCollection, or deleteTag, nor does it specify what type of highlight is being deleted (e.g., text annotation, saved content). This makes it vague in the context of sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a highlight ID from getHighlights), exclusions (e.g., not for bulk operations), or comparisons to siblings like batchDeleteBookmarks or deleteCollection. Without such context, an agent might misuse it or overlook better options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'various formats' but doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'export'), if it requires specific permissions, generates files as output, has rate limits, or involves asynchronous processing (though 'getExportStatus' suggests potential async behavior). The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose, though its brevity contributes to gaps in other dimensions. Every word earns its place by conveying the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and potential complexity (e.g., export operations often involve file generation or async status). It doesn't explain what the tool returns (e.g., a file, a job ID, or status), behavioral constraints, or how it integrates with siblings like 'getExportStatus'. For an export tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters (broken, collectionId, duplicates, format) with descriptions and enum values. The description adds no parameter-specific semantics beyond implying format options with 'various formats', which is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export bookmarks in various formats' clearly states the action (export) and resource (bookmarks), but it's vague about scope and differentiation. It doesn't specify whether this exports all bookmarks, filtered bookmarks, or collections, nor how it differs from sibling tools like 'getBookmarks' or 'searchBookmarks' which might retrieve bookmarks without exporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'getBookmarks' (likely for retrieval) and 'searchBookmarks' (likely for filtered retrieval), the description doesn't clarify that this tool is specifically for exporting data to files rather than just accessing it, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'advanced filters' but doesn't describe pagination behavior (implied by 'page' and 'perPage' parameters), rate limits, authentication requirements, or what happens when no results are found. For a search tool with 10 parameters, this is inadequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loaded with the core purpose. Every word earns its place, with no redundant information or unnecessary elaboration. This is a model of efficient description writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a successful search, what the return format looks like, or how to interpret the various filter parameters in practice. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds no additional parameter semantics beyond mentioning 'advanced filters' generically. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search bookmarks with advanced filters' clearly indicates the verb (search) and resource (bookmarks), but lacks specificity about what constitutes 'advanced filters' and doesn't differentiate from sibling tools like 'getBookmarks' or 'exportBookmarks'. It's vague about the scope of search capabilities beyond mentioning 'advanced filters'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'getBookmarks' (which appears to be a simpler retrieval tool) or 'exportBookmarks'. The description mentions 'advanced filters' but doesn't clarify what makes this tool preferable to other bookmark-related tools in specific contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't mention permissions needed, whether changes are reversible, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., side effects, error cases), usage guidelines relative to siblings, and any mention of return values, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters well-documented in the schema (e.g., 'id' as Bookmark ID, 'collectionId' to move the bookmark). The description adds no parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing bookmark' clearly states the verb ('update') and resource ('bookmark'), but it's vague about what fields can be updated and doesn't distinguish this tool from sibling tools like 'batchUpdateBookmarks' or 'updateCollection'. It provides basic purpose but lacks specificity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'batchUpdateBookmarks' for multiple updates or 'updateCollection' for different resources. The description offers no context about prerequisites, exclusions, or typical use cases, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Update an existing collection' implies a mutation operation, but it doesn't disclose any behavioral traits: no information about permissions required, whether changes are reversible, rate limits, error conditions, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 5 parameters), no annotations, and no output schema, the description is incomplete. It doesn't compensate for the lack of behavioral context or output information. For a tool that modifies collections, more detail on effects, permissions, or response format would be needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters (id, isPublic, sort, title, view) with descriptions and enums. The description adds no meaning beyond what the schema provides—it doesn't explain relationships between parameters, default behaviors, or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing collection' clearly states the verb (update) and resource (collection), but it's vague about what specifically gets updated. It doesn't distinguish this tool from sibling tools like 'mergeCollections' or 'shareCollection' which also modify collections in different ways. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing the collection ID), when not to use it (e.g., for bulk operations vs. batchUpdateBookmarks), or how it differs from similar tools like mergeCollections or shareCollection. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Update an existing highlight' implies a mutation operation, but it doesn't disclose behavioral traits such as required permissions, whether updates are partial or complete, error handling, or side effects. This leaves significant gaps for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects, usage context, and expected outcomes. For a tool that updates data, this minimal description leaves the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'New color', 'Highlight ID'). The description adds no meaning beyond this, as it doesn't explain parameter interactions, constraints, or examples. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing highlight' clearly states the action (update) and resource (highlight), but it's vague about what aspects can be updated. It doesn't distinguish this tool from sibling tools like 'updateBookmark' or 'updateCollection', which follow the same pattern for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing highlight ID), exclusions, or comparisons to similar tools like 'createHighlight' or 'deleteHighlight'. The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It confirms a destructive operation ('Delete') but doesn't disclose critical details: whether deletions are reversible, if permissions are required, what happens on partial failures, or rate limits. The 'permanent' parameter hints at trash behavior, but the description itself doesn't elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word ('Delete multiple bookmarks at once') directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations and no output schema, the description is inadequate. It lacks crucial context: error handling, response format, side effects (e.g., on linked tags/collections), and safety warnings. The agent must rely entirely on the schema for operational details, leaving behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning about 'ids' or 'permanent' beyond implying batch scope. It doesn't explain ID formats, array size limits, or the implications of permanent deletion. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete multiple bookmarks') and resource ('bookmarks'), making the purpose immediately understandable. It distinguishes from single-delete sibling 'deleteBookmark' by specifying 'multiple... at once', though it doesn't explicitly contrast with other bulk operations like 'bulkMoveBookmarks' or 'bulkTagBookmarks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing bookmark IDs), compare to single-delete 'deleteBookmark', or explain when batch deletion is preferable over other bulk operations like 'bulkMoveBookmarks'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Update multiple bookmarks at once' implies a mutation operation but doesn't disclose behavioral traits like whether it's idempotent, what happens on partial failures, if it requires specific permissions, or the response format. For a batch mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Update multiple bookmarks at once' is front-loaded and appropriately sized for the tool's complexity. Every word earns its place by conveying the core action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'update' entails (e.g., which fields can be modified), behavioral aspects like error handling, or the return values. The agent must rely entirely on the input schema, leaving gaps in understanding the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters (ids, collectionId, important, tags). The description adds no additional meaning beyond implying batch capability, which is already evident from the name and parameter structure. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple bookmarks at once' clearly states the verb ('Update') and resource ('bookmarks'), with the qualifier 'multiple...at once' distinguishing it from the sibling tool 'updateBookmark'. However, it doesn't specify what aspects of bookmarks can be updated (e.g., tags, importance, collection), which would make it fully distinct from other batch operations like 'bulkMoveBookmarks' or 'bulkTagBookmarks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'bulkMoveBookmarks', 'bulkTagBookmarks', and 'updateBookmark', the agent must infer usage from the name alone. There's no mention of prerequisites, constraints, or comparative scenarios (e.g., 'use this for mixed updates instead of specialized bulk tools').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Move' implies a mutation operation, it doesn't specify whether this is destructive (overwrites existing data), requires specific permissions, has rate limits, or what happens to bookmarks already in the target collection. For a bulk mutation tool, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately front-loaded with the main action and scope, making it easy to parse quickly. Every word earns its place in this minimal but complete statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address critical context like error handling, whether the operation is atomic, what confirmation is provided, or how to verify success. Given the complexity of moving multiple resources and the lack of structured safety information, more behavioral disclosure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters ('collectionId' as target collection ID, 'ids' as list of bookmark IDs). The description adds no additional semantic context beyond what's in the schema, such as format examples, constraints on ID validity, or what happens with invalid IDs. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and resources ('multiple bookmarks to another collection'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'batchUpdateBookmarks' or 'updateBookmark' which might also involve bookmark modifications, leaving room for ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'batchUpdateBookmarks' and 'updateBookmark' available, there's no indication of whether this is for bulk relocation only, if it's more efficient for large moves, or if it should be preferred over individual updates. The lack of context makes tool selection challenging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Add or remove tags' implies mutation, it doesn't disclose critical behavioral aspects: whether this requires specific permissions, if operations are atomic (all-or-nothing), what happens with invalid IDs/tags, rate limits, or error handling. For a bulk mutation tool, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality without any wasted words. It's appropriately sized for a tool with clear parameters and no complex behavioral nuances needing explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk mutation tool with no annotations and no output schema, the description is insufficient. It doesn't address permissions, error handling, atomicity, or what the tool returns. Given the complexity of modifying multiple resources and the lack of structured safety information, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear documentation for all three parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, format details, or constraints). This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add or remove tags') and resource ('multiple bookmarks'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'batchUpdateBookmarks' or 'updateBookmark' which might also modify bookmarks, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'batchUpdateBookmarks', 'updateBookmark', and 'renameTag' available, there's no indication whether this is for bulk operations only, specific to tag management, or how it differs from other bookmark modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description doesn't specify whether this requires authentication, what happens on success/failure, if there are rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward creation tool and is front-loaded with the essential information. Every word earns its place in this concise formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 no output schema, the description is insufficiently complete. It doesn't explain what happens after creation, what the return value might be, or any error conditions. While the schema covers parameters well, the overall context for using this tool remains incomplete, especially given its write nature and lack of structured behavioral hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all four parameters. The baseline score of 3 reflects that the schema adequately documents parameters, so the description doesn't need to compensate, but also doesn't add any additional semantic context about how parameters interact or their practical usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and target resource ('a new highlight for a bookmark'), making the purpose immediately understandable. It distinguishes from sibling tools like 'updateHighlight' and 'deleteHighlight' by specifying creation rather than modification or deletion. However, it doesn't explicitly differentiate from 'getAllHighlights' or 'getHighlights' which are read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'updateHighlight' or 'deleteHighlight'. It doesn't mention prerequisites (e.g., needing an existing bookmark), nor does it specify scenarios where this tool is appropriate versus when other highlight-related tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this operation is reversible, requires specific permissions, has side effects (e.g., on the bookmark itself), or returns any confirmation. For a destructive tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Delete') and immediately specifies the target. There's no redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like success/failure responses, error conditions, or the impact on the bookmark (e.g., whether the bookmark remains intact). For a mutation tool with no structured safety or output information, this leaves significant gaps for an agent to operate safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'raindropId' documented as 'Bookmark ID' in the schema. The description adds no additional parameter semantics beyond this—it doesn't explain what a 'raindropId' is, how to obtain it, or its relationship to reminders. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a reminder from a bookmark'), which is specific and unambiguous. It distinguishes itself from sibling tools like 'deleteBookmark' or 'deleteCollection' by focusing specifically on reminders, not the bookmarks themselves. However, it doesn't explicitly mention what happens to the bookmark after reminder deletion or the scope of deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a reminder must exist), exclusions, or relationships with sibling tools like 'setReminder' (which likely creates reminders) or 'deleteBookmark' (which might delete the entire bookmark). The agent must infer usage context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool removes a tag, implying a destructive operation, but doesn't clarify whether this is reversible, what permissions are required, or how it affects associated bookmarks. The phrase 'from all bookmarks or in a specific collection' hints at scope but lacks detail on error handling or confirmation prompts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and immediately clarifies the optional scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It lacks critical details like whether the operation is permanent, what happens to bookmarks after tag removal, error conditions, or return values. The presence of sibling tools like 'deleteTags' and 'renameTag' further highlights the need for clearer differentiation and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('Tag to delete' and 'Collection ID (optional)'). The description adds minimal value beyond the schema by implying the optional 'collectionId' restricts scope to a specific collection, but doesn't elaborate on format, constraints, or interaction between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a tag') and the target ('from all bookmarks or in a specific collection'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'deleteTags' (plural) or 'renameTag', leaving some ambiguity about when to choose this tool over those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two usage contexts (all bookmarks vs. specific collection) but provides no guidance on when to choose one over the other, nor does it reference any sibling tools like 'deleteTags' or 'renameTag' as alternatives. There's no mention of prerequisites, side effects, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive operation, the description doesn't specify whether this action is reversible, what permissions are required, whether it affects all users' bookmarks or just the current user's, or what happens when tags are deleted from bookmarks (do bookmarks lose those tags entirely?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple operation and front-loads the essential information (action and target).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain the consequences of deleting tags from bookmarks, whether this affects bookmarks across all collections or just specific ones, what the response looks like, or any error conditions. The optional collectionId parameter's effect on scope remains ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (tags as required array, collectionId as optional number). The description mentions 'all bookmarks' which implies global scope, but doesn't clarify how the optional collectionId parameter modifies this scope or what happens when it's omitted versus provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('tags from all bookmarks'), providing a specific verb+resource combination. However, it doesn't differentiate from the sibling tool 'deleteTag' (singular vs plural), which could cause confusion about when to use each tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'deleteTag' (singular) and 'bulkTagBookmarks' available, there's no indication of whether this tool applies to all bookmarks globally, within a collection, or how it differs from other deletion/tagging operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't cover critical aspects like whether this is a read-only operation, pagination behavior, rate limits, authentication needs, or error handling. For a tool with two parameters and no annotations, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits needed for safe invocation. For a tool with pagination parameters and no structured output, more context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'page' and 'perPage'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without compensating or detracting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all highlights across all bookmarks', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getHighlights' or 'getHighlightsByCollection', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'getHighlights' or 'getHighlightsByCollection'. It lacks context about use cases, prerequisites, or exclusions, leaving 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't clarify if this is a read-only operation, what happens if the ID is invalid (e.g., error handling), or any rate limits or authentication needs. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action and resource, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what is returned (e.g., bookmark details, error formats) or address potential behavioral aspects like permissions or side effects, which are crucial for a tool that fetches data by ID in a system with multiple related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID', which aligns with the single parameter 'id' in the input schema. Since schema description coverage is 100%, the schema already documents the parameter type and requirement, so the description adds minimal value beyond restating the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific bookmark by ID'), making the purpose unambiguous. However, it doesn't distinguish this tool from similar siblings like 'getBookmarks' (plural) or 'searchBookmarks', which could retrieve bookmarks differently, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getBookmarks' (for listing) and 'searchBookmarks' (for filtered searches), the agent is left to infer usage based on the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a collection but doesn't cover critical aspects like whether it's a read-only operation, authentication requirements, error handling (e.g., if the ID doesn't exist), or rate limits. This leaves significant gaps in understanding the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly. This exemplifies optimal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., collection details, error responses) or behavioral traits like side effects. For a retrieval tool in a server with many sibling operations, more context is needed to ensure the agent can use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Collection ID' and type 'number'. The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific collection by ID'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'getCollections' (which likely lists multiple collections) or 'getBookmark' (which retrieves a different resource type), missing explicit differentiation that would warrant a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'getCollections' for listing collections or 'getBookmarks' for retrieving bookmarks, nor does it specify prerequisites or exclusions. This lack of context leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves highlights but doesn't mention whether this is a read-only operation, what permissions are needed, how results are formatted, or any rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'highlights' are, how they are returned, or any behavioral traits like error handling. For a tool with no structured support, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies the parameter 'raindropId' identifies a bookmark, but the schema already provides 100% coverage with a clear description ('Bookmark ID'). No additional semantic context is added, such as where to find the ID or format examples, so it meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get highlights') and the target resource ('for a specific bookmark'), which is a specific verb+resource combination. However, it doesn't distinguish itself from sibling tools like 'getAllHighlights' or 'getHighlightsByCollection', which handle highlights retrieval differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getAllHighlights' or 'getHighlightsByCollection'. It lacks explicit instructions on prerequisites, exclusions, or comparative contexts, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a read operation ('Get highlights') but lacks details on permissions, rate limits, pagination, or return format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'highlights' are, how they're returned, or any behavioral traits like error handling. For a tool in a context with many siblings, more context is needed to ensure proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'collectionId' parameter as a number. The description adds no additional meaning beyond implying it's used to specify a collection, which is redundant with the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get highlights') and target resource ('for bookmarks in a specific collection'), which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getAllHighlights' or 'getHighlights' (which likely fetch highlights without collection filtering), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getAllHighlights' or 'getHighlights', nor does it mention prerequisites or exclusions. It merely states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get user information' implies a read-only operation, but it doesn't specify authentication requirements, rate limits, error handling, or what the output looks like (e.g., JSON structure). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, 'Get user information', which is front-loaded and wastes no space. Every word contributes to the core purpose, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal. While it states the purpose, it lacks context on usage, behavioral traits, or output format. For a tool in a server with many siblings, more completeness is needed to guide the agent effectively, such as distinguishing from 'getUserStats' or explaining return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. Baseline is 4 for 0 parameters, as no additional semantic information is needed beyond the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user information' clearly states the verb ('Get') and resource ('user information'), making the purpose understandable. However, it's somewhat vague about what specific user information is retrieved (e.g., profile details, preferences, stats) and doesn't differentiate from sibling tools like 'getUserStats', which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'getUserStats' available, it doesn't specify if this tool is for general user data, while 'getUserStats' might be for metrics, or if they serve different contexts. No exclusions 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but reveals little. It states the merge action but doesn't disclose critical behaviors: whether source collections are deleted or preserved after merging, what happens to their contents, if permissions are required, or what the output looks like. This leaves significant gaps for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 no output schema, the description is incomplete. It doesn't explain what 'merge' entails operationally (e.g., combining contents, deleting sources), potential side effects, or return values. Given the complexity of merging collections, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional semantic context about parameters beyond implying 'multiple' for sourceIds and 'one' for targetId, which is already evident from the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'merge' and the resource 'collections', specifying that multiple source collections are combined into one target collection. However, it doesn't differentiate from sibling tools like 'bulkMoveBookmarks' or 'mergeTags' which perform similar consolidation operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., collections must exist), exclusions (e.g., cannot merge a collection into itself), or compare with similar operations like 'bulkMoveBookmarks' for moving bookmarks between collections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like what happens to source tags after merging (are they deleted?), whether this requires specific permissions, or any side effects. 'Merge' implies mutation but lacks details on consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resources, making it immediately clear without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens to source tags, or potential errors. Given the complexity of merging operations, more context is needed for an agent to use this effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds no additional meaning beyond what the schema provides about parameters, but doesn't contradict it either. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('merge') and resources ('multiple tags into one destination tag'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'renameTag' or 'deleteTag' which also operate on tags, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'renameTag' or 'deleteTag', nor does it mention prerequisites or context for merging tags. There's no explicit when/when-not usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Set a reminder' implies a write operation, but it doesn't disclose behavioral traits like whether this overwrites existing reminders, requires specific permissions, has rate limits, returns confirmation data, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 3 parameters, the description is incomplete. It lacks behavioral context (e.g., what the tool returns, error handling), usage guidelines, and doesn't compensate for the absence of structured data. For a tool that creates reminders, more detail is needed to guide an AI agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for date (ISO format), note (reminder note), and raindropId (bookmark ID). The description adds no parameter semantics beyond what the schema provides, but the schema adequately documents all parameters, meeting the baseline score of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a reminder for a bookmark' clearly states the action (set) and target resource (reminder for a bookmark). It distinguishes from siblings like deleteReminder (which removes reminders) and createBookmark (which creates bookmarks), but doesn't specify how it differs from similar reminder-related tools since none exist in the sibling list beyond deleteReminder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing bookmark), exclusions, or comparisons to other tools like updateBookmark that might have reminder-related functionality. The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Share' implies a write operation with permission changes, but it doesn't disclose critical traits like whether it's idempotent, requires specific user permissions, affects existing shares, or returns confirmation data. For a mutation tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action ('share') and resource ('collection'), making it easy to parse. Every word earns its place by conveying the essential purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 3 parameters, no annotations, and no output schema), the description is inadequate. It lacks details on behavioral outcomes, error conditions, or return values, leaving the agent to guess about success responses or side effects. For a permission-changing tool, this creates significant uncertainty in usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters (id, level, emails). The description adds no additional meaning beyond implying these parameters exist for sharing. It doesn't explain relationships between parameters (e.g., 'emails' is optional, 'level' choices affect access) or provide usage examples, so it meets the baseline but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('share') and resource ('a collection'), making the purpose immediately understandable. It distinguishes from siblings like 'createCollection' or 'mergeCollections' by focusing on permission management rather than creation or merging. However, it doesn't specify what 'share' entails beyond the basic concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a collection ID), exclusions (e.g., not for sharing bookmarks directly), or related tools like 'updateCollection' that might handle permissions differently. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'permanently deletes' items, which implies a destructive, irreversible action, but lacks details on permissions needed, rate limits, error conditions, or what happens if the trash is already empty. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('empty the trash') and adds clarifying detail ('permanently deleting all raindrops in it'). There is zero waste, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of annotations or output schema, the description is incomplete. It fails to address critical aspects like confirmation prompts, return values (e.g., success status or error messages), or safety warnings, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter information, which is appropriate here, but it doesn't compensate for any gaps since there are none. A baseline of 4 is applied as it meets the requirement for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('empty the trash') and the resource ('raindrops in it'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'deleteBookmark' or 'batchDeleteBookmarks', which might also delete content but not specifically from the trash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the trash must contain items), exclusions (e.g., if it's irreversible), or compare it to sibling deletion tools, leaving the agent with no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get all collections' implies a read operation but doesn't specify whether it returns all collections at once, uses pagination, requires authentication, has rate limits, or what format the data returns. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get all collections') - just three words that directly convey the core purpose. It's front-loaded with the essential information and has zero wasted words. This is an excellent example of efficiency in description writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and the description provides minimal behavioral context, this is incomplete for effective agent use. While the purpose is clear, the agent lacks information about what 'all collections' means (scope, format, limitations) and how the tool behaves. For a read operation with zero structured metadata, the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema is fully described). With no parameters to document, the description doesn't need to add parameter semantics. The baseline for 0 parameters is 4, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all collections' clearly states the verb ('Get') and resource ('collections'), making the purpose immediately understandable. It distinguishes from siblings like 'getCollection' (singular) and 'mergeCollections', but doesn't explicitly contrast with other collection-related tools like 'createCollection' or 'deleteCollection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'getCollections' versus 'getCollection' (singular), 'getHighlightsByCollection', or other collection-related tools like 'mergeCollections' or 'shareCollection'. No context about prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose what status values might be returned, whether this is a polling operation, what happens if the export doesn't exist, or any rate limits. The description is too sparse for a status-checking tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status-checking tool with no annotations and no output schema, the description is incomplete. It doesn't explain what information will be returned, what statuses are possible, or how to interpret results. The agent would need to guess about the tool's behavior and output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the parameter situation. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not creating confusion about non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check') and resource ('status of an ongoing export'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'getImportStatus' which has a similar checking pattern, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an export ID from 'exportBookmarks'), nor does it clarify what constitutes 'ongoing export' versus completed/failed exports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'ongoing import' suggesting it tracks active processes, but doesn't disclose what status values to expect, whether it's read-only (implied but not stated), error conditions, or polling requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple status-checking tool and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. It doesn't explain what status information is returned, format of response, or how to interpret results. For a status-checking tool with zero structured metadata, more context about expected outputs is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and target ('status of an ongoing import'), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'getExportStatus' which follows a similar pattern for exports, missing an opportunity for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an import ID from a previous operation), timing considerations, or how it relates to other import/export tools like 'getExportStatus'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Remove all empty collections' implies a destructive operation but doesn't specify whether this is reversible, what permissions are required, whether it affects child resources, or what happens if no empty collections exist. For a potentially destructive tool with zero annotation coverage, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately scannable. Every word earns its place in conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a potentially destructive operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'empty' means (e.g., no bookmarks, no subcollections), what confirmation might be needed, what the return value looks like, or error conditions. For a tool that could delete multiple resources, this level of documentation is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the input interface. The description doesn't need to explain parameters, and it correctly avoids mentioning any. The baseline for zero parameters is 4, as there's no parameter information to add beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target resource ('all empty collections'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'deleteCollection' or 'emptyTrash', but the verb+resource combination is specific enough to convey the tool's function without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'deleteCollection' (which might handle non-empty collections) or 'emptyTrash' (which might handle trashed items). There's no mention of prerequisites, consequences, or appropriate contexts for invoking this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('Rename a tag') but doesn't disclose behavioral traits such as whether it requires specific permissions, if it's idempotent, what happens to bookmarks with the old tag, error conditions (e.g., duplicate new names), or response format. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Rename a tag') and adds necessary scope information. There is zero waste, and every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 3 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, errors, effects), doesn't fully explain parameter usage beyond schema hints, and provides no information on return values or side effects, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (oldName, newName, collectionId). The description adds minimal value by hinting at the scope ('across all bookmarks or in a specific collection'), which relates to the optional 'collectionId', but doesn't provide additional syntax, format details, or constraints beyond what the schema offers. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Rename') and resource ('a tag'), specifying the scope ('across all bookmarks or in a specific collection'). It distinguishes from siblings like 'deleteTag', 'mergeTags', or 'bulkTagBookmarks' by focusing on renaming rather than deletion, merging, or bulk operations. However, it doesn't explicitly contrast with 'mergeTags' (which might involve renaming during merging), leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the scope ('across all bookmarks or in a specific collection'), suggesting it can be used broadly or narrowly. However, it lacks explicit guidance on when to use this vs. alternatives like 'mergeTags' (for combining tags) or 'deleteTag' (for removal), and doesn't specify prerequisites (e.g., tag existence) or exclusions (e.g., invalid names).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![raindrop-mcp MCP server](https://glama.ai/mcp/servers/adeze/raindrop-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adeze/raindrop-mcp)

Score Badge

Copy to your README.md:

[![raindrop-mcp MCP server](https://glama.ai/mcp/servers/adeze/raindrop-mcp/badges/score.svg)](https://glama.ai/mcp/servers/adeze/raindrop-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adeze/raindrop-mcp'

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