Linklore MCP vs Scrivener MCP — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Linklore MCP vs Scrivener MCP
In-depth architectural comparison of the Linklore MCP and Scrivener MCP MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
Linklore MCP
Knowledge & Memory · Local stdio
Quality: 57/100 (Good) | Auth: No auth required
Scrivener MCP
Knowledge & Memory · Local stdio
Quality: 61/100 (Good) | Auth: No auth required
Verdict Summary: Choose Linklore MCP if you need specialized Knowledge & Memory tools running via a local process. Choose Scrivener MCP if your workspace requires Knowledge & Memory integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose Linklore MCP when:
You need dedicated capabilities in the Knowledge & Memory domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
AI-native structured memory for coding agents — typed lore/doc entries with status and links, read and written by agents via MCP.
Connect Scrivener 3 writing projects to Claude and other AI assistants. 47 tools for document management, writing analysis, semantic search, character/plot memory, and content enhancement. Progressive skill loading, relationship engine with HMS triplets, and JS fallback for offline semantic search. npm i -g scrivener-mcp
Category & Scope
Tools & Capabilities Breakdown
Linklore MCP Tools (24)
doc_flow
[read-only] doc_flow(id) — renders a doc's flowLink chain in order (journey view).
doc_map
[read-only] doc_map(oneline) — overview of the full doc link network.
brief
project dashboard — call at the start of every session.
external source 🔔 = a new push has arrived. receive it with openbox(action='show').
options: dismiss(turn off a nudge), undismiss(restore it), help.
init
init(blueprint='') — set up .linklore in this directory (starts local footprint memory).
- init() basic setup
- init(blueprint='X') apply a blueprint
project_dir: set up .linklore in another folder (creating a boundary is init-only). setting up there doesn't change this session's base project — to keep working there, config(action='pin').
config
Project settings (openbox source options) + iam + session pin.
WARNING: handle/name/email apply machine-wide, not per-project.
Sharing lives in a separate tool: openbox (openbox sharing/members).
11 actions:
- action='whoami' → your identity (handle/name/email)
- action='version' → server code version (git commit)
- action='sources' → list registered external sources (openboxes)
- action='option' → change an external source's settings (auto_search=/show_prefix=)
- action='sync' → force-refresh an external source's cache
- action='forget' → deregister an external source
- action='pin' → pin this session to a specific project
- action='unpin' → unpin the session
- action='sessions' → list/revoke your account sessions (revoke=)
- action='projects' → list every LinkLore project on this machine
- action='delete_project' → permanently delete your personal-server copy of this project (returns guidance, no execution — use the forced() command it prints)
help=true for details.
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
Linklore MCP is categorized under Knowledge & Memory and uses a local stdio subprocess. In contrast, Scrivener MCP belongs to Knowledge & Memory using local stdio subprocess. Select Linklore MCP when you need capabilities focused on knowledge & memory and Scrivener MCP when you require tools for knowledge & memory.
status() — detects code↔doc sync drift (git-diff based). Not for reading lore/doc content → use show()/brief().
since, action(''|'ack'|'reset'), ack, reset, help.
link
link(a, b, action=) — connect two items (dc↔dc / lr↔lr / dc↔lr auto-detected, prefix matching OK).
a/b may also be a file path or an existing title — non-id-shaped values are auto-classified (same as links= in add/edit).
Undo (inverse) = unlink(a, b) — same arguments.
action has 5 modes (extends the member/config(action=) convention):
- action='related' (default, same if omitted) → mutual link (symmetric). Same as link(a, b) — dc↔dc/lr↔lr/dc↔lr
- action='flow' → not a mutual link but **document order** (a→b direction, doc↔doc only): read a, then b.
- action='supersede' → "a is replaced by b" — a=old (dropped, head=False/dropped), b=target (alive,
must be an existing item — none is created). lore↔lore or doc↔doc only.
- action='unrelated' → verdict: not related — this pair stops appearing as related candidates or duplicate alerts (not a link, a stored verdict).
- action='distinct' → verdict: not a duplicate (confirmed separate) — only duplicate alerts are silenced, it still appears as a related candidate.
The 4 suggestion verdicts: related-yes=link(a,b) · duplicate-yes=action='supersede' · related-no=action='unrelated' · duplicate-no=action='distinct'
unlink
unlink(a, b, action=) — disconnect two items or clear a verdict. Symmetric with link() (action='' default|'flow'|'unrelated'|'distinct', also accepts file paths the same way).
doc_rollup
[read-only] doc_rollup(id) — find and collect lore linked to a doc into an AI-summary draft.
cleanup
[read-only] cleanup(type='lore'|'doc') threshold(=0.85), status(=open), help - duplicate candidates.
doctor
doctor() - checks project data integrity (oldId/newId, files[] paths, link targets).
doctor() read-only diagnostics (default)
doctor(action='fix') automatically repairs any issues found
forced
Executes the exact destructive action described in a warning printed by rm(), local_cross(), config(), or openbox() — copy the values from that warning verbatim. Do not call this on your own initiative; only call it after seeing a warning that names it and tells you exactly what to pass.