A Model Context Protocol server for interacting with LinkDing bookmark manager
LinkDing MCP server has well-structured tool definitions with complete input schemas and consistent naming conventions. All 9 tools follow a verb_noun pattern (search_, add_, get_, update_, delete_, archive_, unarchive_, check_). Descriptions are present for all tools and most parameters. However, several gaps reduce overall quality: (1) Output schemas are not documented, tools return 'JSON string' without specifying field structure, breaking the LLM's ability to plan downstream calls. (2) Many descriptions lack actionable detail about when to use a tool vs. similar alternatives (e.g., get_bookmark vs. search_bookmarks distinction). (3) Parameter descriptions exist but are often generic (e.g., 'The ID of the bookmark to delete' rather than 'Bookmark ID (integer, 1-999999)'). (4) No error handling guidance, responses mention 'Success or error message' without explaining recovery paths. (5) No destructive operation guidance in descriptions despite delete_bookmark being DESTRUCTIVE risk class. These are foundational issues preventing A-grade scores.
Add a new bookmark to LinkDing. Args: url: The URL to bookmark (required) title: Custom title for the bookmark (auto-scraped if not provided) description: Custom description (auto-scraped if not provided) notes: Personal notes for the bookmark tags: List of tag names to assign to the bookmark is_archived: Whether to save the bookmark directly to archive unread: Mark the bookmark as unread shared: Make the bookmark shared with other users Returns: JSON string containing the created bookmark data
Archive a bookmark by moving it to the archive without deleting it. Args: bookmark_id: The ID of the bookmark to archive Returns: Success or error message
Check if a URL is already bookmarked and return bookmark details if it exists. Args: url: The URL to check Returns: JSON string with check results and bookmark details if found
Delete a bookmark by its ID. Args: bookmark_id: The ID of the bookmark to delete Returns: Success or error message
Retrieve a specific bookmark by its ID. Args: bookmark_id: The ID of the bookmark to retrieve Returns: JSON string containing the bookmark data
Output schemas not documented for any tool. Tools return 'JSON string containing...' but LLMs cannot see the actual field structure, breaking downstream tool composition and forcing parsing guesswork.
Destructive tool (delete_bookmark) lacks warning and confirmation guidance in description. Per pattern:confirmation-request, irreversible operations should mention dry-run or confirmation steps. Description is only 44 characters and doesn't warn about permanence.
Parameter descriptions lack format constraints and validation rules. E.g., bookmark_id parameter says 'The ID of the bookmark' without specifying type range (1-999999?), URL parameter has no validation guidance (must be HTTP/HTTPS? max length?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Get all tags from LinkDing. Args: limit: Maximum number of results to return (default: 100) offset: Number of results to skip for pagination (default: 0) Returns: JSON string containing the list of tags
Search for bookmarks with various filters. Args: query: Search phrase to filter bookmarks (searches title, description, notes, URL) tag: Filter by specific tag name limit: Maximum number of results to return (1-1000, default: 100) offset: Number of results to skip for pagination (default: 0) archived: Search in archived bookmarks instead of active ones unread_only: Only return unread bookmarks Returns: JSON string containing the search results
Restore a bookmark from the archive to active bookmarks. Args: bookmark_id: The ID of the bookmark to unarchive Returns: Success or error message
Update an existing bookmark. Args: bookmark_id: The ID of the bookmark to update url: New URL for the bookmark title: New title for the bookmark description: New description for the bookmark notes: New notes for the bookmark tags: New list of tag names (replaces existing tags) is_archived: Update archived status unread: Update unread status shared: Update shared status Returns: JSON string containing the updated bookmark data
No error handling guidance. Tools return 'Success or error message' but don't tell the LLM what to do on failure. E.g., if add_bookmark fails due to invalid URL, should the LLM retry? Ask user? Call check_url first? Per pattern:recovery-guide, errors must guide next steps.
Parameter interdependencies undocumented. E.g., update_bookmark doesn't clarify: if 'tags' is omitted, are existing tags cleared or preserved? Does setting is_archived=true reset unread flag?
Tool selection hints missing. Descriptions don't explain when to use search_bookmarks vs. get_bookmark, or get_tags vs. using tags parameter in search.
Auto-scraping behavior in add_bookmark not explained. Description says 'auto-scraped if not provided' but doesn't document: scraping timeout, error handling (404, timeout?), engine details, or time impact. Critical for agent planning and retry logic.
Pagination design inconsistency. search_bookmarks uses limit (default 100) and offset; get_tags uses same params with same defaults. But no guidance on whether to use limit=1000 to fetch all or whether max is enforced.