Add an MCP server for LinkAce

[Kovah]

LinkAce already exposes a solid REST API, but it would be useful to make LinkAce available through the Model Context Protocol (MCP) as well.

An MCP server would let AI clients and agent frameworks interact with LinkAce in a structured way instead of relying on custom integrations or direct HTTP calls. That could make LinkAce a much better fit for workflows like bookmark search, link saving, tagging, list management, and knowledge retrieval from AI tools.

Why this would be useful

• Expose LinkAce as a standard tool source for MCP-compatible clients
• Make bookmark search and retrieval easier from AI assistants
• Allow creating and updating links, lists, tags, and notes from MCP tools
• Reuse the existing LinkAce API model instead of every integration inventing its own adapter
• Potentially improve discoverability of LinkAce in AI-assisted personal knowledge workflows

Possible scope

A first version could stay narrow and map MCP tools onto the existing API:

• search_links
• get_link
• create_link
• update_link
• list_lists
• list_tags
• get_links_by_list
• get_links_by_tag

Later versions could expand into:

• notes
• bulk operations
• trash/restore flows
• saved searches or richer query support

Main questions that need to be answered

1. How should this be implemented?

Open questions:

• Should the MCP server live inside the main LinkAce app, or as a separate companion service?
• Should it directly call internal application services, or should it be a thin wrapper around the existing REST API?
• Would it be better to start with a local stdio MCP server, an HTTP-based MCP server, or both?
• How closely should MCP resources/tools map to current API endpoints and policies?

A thin wrapper around the existing API is probably the simplest starting point, because it keeps one source of truth for business rules and permissions.

2. What should authentication look like?

This is likely the hardest product question.

Open questions:

• Should MCP clients authenticate with existing personal API tokens?
• Do we need MCP-specific tokens with narrower scopes than the current API tokens?
• Should tokens be bound to a user only, or also to a specific MCP client/device/session?
• Do we need token expiry, rotation, or revocation UX specifically for MCP use?
• Should OAuth-based flows be supported for remote MCP clients?

A reasonable first step might be to reuse existing API tokens if they already support the required scopes cleanly. If not, MCP-specific scoped tokens may be necessary.

3. How do we make this secure?

This part needs careful design, especially because MCP can expose write operations to AI tools.

Open questions:

• Which operations should be read-only in v1, and which write actions are safe to expose?
• How do we prevent over-broad access to private links, notes, lists, or multi-user data?
• Should write actions require extra confirmation or stricter scopes?
• How do we audit MCP-originated actions?
• How do we rate-limit or isolate MCP access from the normal API?
• How do we prevent prompt-driven misuse from turning into destructive API calls?

Some guardrails that seem worth considering:

• start read-only if needed
• require least-privilege token scopes
• log MCP-originated actions separately
• keep all existing authorization and ownership checks in place
• clearly separate per-user access in multi-user setups
• avoid bypassing the existing API permission model

Suggested acceptance criteria

• A documented decision on architecture: embedded vs companion service
• A documented authentication model
• A documented security model and scope boundaries
• A minimal MCP prototype that can at least search and read links
• Clear mapping between MCP tools and existing LinkAce API capabilities

Notes

LinkAce already has a REST API and token-based authentication, so this may be more about designing a safe MCP layer than building entirely new data access logic.

The key question is not just “can LinkAce expose MCP?”, but “how can it do that without weakening the existing security and permission model?”