Linklore MCP vs Moxie Docs MCP — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
Linklore MCP vs Moxie Docs MCP
In-depth architectural comparison of the Linklore MCP and Moxie Docs 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
Moxie Docs MCP
Knowledge & Memory · Local stdio
Quality: 80/100 (Excellent) | Auth: API Key required
Verdict Summary: Choose Linklore MCP if you need specialized Knowledge & Memory tools running via a local process. Choose Moxie Docs 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.
MCP & Agent Skills for Automated Documentation, and codebase conventions + context
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, Moxie Docs MCP belongs to Knowledge & Memory using local stdio subprocess. Select Linklore MCP when you need capabilities focused on knowledge & memory and Moxie Docs 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.
+12 more tools listed on main page
Moxie Docs MCP Tools (12)
moxie.get_ai_context
Compact pre-edit briefing: repo status, verified commands, top conventions, open gaps, team notes. Read this first.
moxie.get_doc_impact
Given the paths you're about to change (and any you're deleting), returns the conventions, gaps, and existing docs whose evidence overlaps them - and flags net-new/undocumented surfaces.
moxie.get_api_context
Given paths you're about to touch, returns structured context for any API endpoints they map to: method, path, schema, and known consumers/features.
moxie.review_change
Self-review a change before opening the PR; returns a severity-ranked verdict (clean / warnings / must-fix) covering convention breaches, stale docs, undocumented surface, and broken references.
moxie.get_conventions
Discovered coding conventions, grouped by category, with confidence scores, agent guidance, and source-file citations.
moxie.search_docs
Semantic + keyword search over generated docs, conventions, gaps, and AI context.
moxie.get_doc_gaps
Unresolved documentation gaps with severity and the paths they concern.
moxie.get_documentation_opportunities
Recommended doc work: missing docs, drift repairs, and PR templates.
moxie.get_documentation_patterns
How the repository organizes and maintains its docs (where new docs belong).
moxie.list_docs
Paginated, section-grouped table of contents of every generated doc.
moxie.propose_doc_update
Add or update a doc as part of your current change; returns the target path + Markdown to write into your branch.
moxie.propose_doc_removal
Remove a Moxie-tracked doc your change makes obsolete; returns the path to delete in your branch.