ต้นแบบ · รุ่นทดลอง: มีทุก server ในทะเบียนทางการ อัปเดตทุก 30 นาที รีวิวและบัญชีผู้ใช้จะมาในขั้นถัดไป
PopNx MCPที่รวม MCP สำหรับคนใช้ AI · อธิบายเป็นภาษาคน

Limpet

โดย KSym04รุ่น 0.17.0i★ –i–
ชื่อใน registryio.github.KSym04/limpet

ติดตั้ง

ภาพรวม

คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)

Persistent engineering memory for AI coding agents. Survives refactors, knows when it is stale.

สามเสาของ PopNx MCP

สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน

ใช้ทำอะไรได้

ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry

  • การเชื่อมต่อ: –
  • ช่องทาง (transport):
  • หมวด: ค้นข้อมูลและความจำของ AI

ติดตั้ง

เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง

ก่อนติดตั้ง

ผู้ทำยังไม่ได้ใส่วิธีติดตั้งใน registry ให้ดู README ของผู้ทำด้านล่าง

ทำอะไรได้บ้าง

รันในเครื่องคุณ รายการเครื่องมือจะขึ้นในแอป AI หลังติดตั้ง

ผลตรวจเบื้องต้นi

เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 7 พ.ย. 2569

  • ✓ ผ่าน

    ตัวตนผู้ทำตรงกับ repo

    ชื่อใน registry ยืนยันด้วยบัญชี GitHub KSym04 ซึ่งเป็นเจ้าของ repo

  • … ยังไม่ตรวจ

    ยังมีคนดูแล

    ยังไม่ได้อ่านข้อมูล repo จาก GitHub

  • … ยังไม่ตรวจ

    มีสัญญาอนุญาต (license)

    ยังไม่ได้อ่านข้อมูล repo จาก GitHub

  • – ไม่เกี่ยว

    endpoint ตอบ

    ตัวนี้รันบนเครื่องคุณ ไม่มี endpoint บนอินเทอร์เน็ต

  • – ไม่เกี่ยว

    ล็อกอินแบบ OAuth

    ตัวนี้รันบนเครื่อง ใช้ค่าที่ตั้งในเครื่องแทน

  • … ยังไม่ตรวจ

    คำอธิบายเครื่องมือไม่มีคำสั่งแอบแฝง

    รันในเครื่องคุณ เราอ่านรายการเครื่องมือได้เฉพาะตัวที่มี endpoint บนอินเทอร์เน็ต

เทียบกับตัวอื่นในหมวด ค้นข้อมูลและความจำของ AIi

  • ดาวมากกว่า 0% ของอีก 7251 ตัวในหมวดนี้
  • ส่งรุ่นใหม่เข้า registry ล่าสุดกว่า 40% ของอีก 7251 ตัวในหมวดนี้
  • ผลตรวจเบื้องต้นดีกว่าหรือเท่ากับ 100% ของอีก 7251 ตัวในหมวดนี้

เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo

คำถามที่พบบ่อย

Limpet ปลอดภัยไหม?

จากการตรวจเบื้องต้นของเรา ผ่าน 1 จาก 1 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น

ต้องใช้กุญแจหรือรหัสอะไรบ้าง?

registry ไม่ได้ระบุว่าต้องใช้กุญแจ แต่บางตัวจะขอให้ล็อกอินตอนใช้ครั้งแรก

ตัวนี้รันบนเครื่องหรือบนคลาวด์?

รันบนเครื่องของคุณ โปรแกรม AI จะเปิด server ขึ้นมาเองเมื่อใช้ ข้อมูลไม่ต้องผ่านเซิร์ฟเวอร์ของผู้ทำ (ยกเว้นตัวที่ไปเรียกบริการออนไลน์ต่อ)

ยังมีคนดูแลอยู่ไหม?

repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (0.17.0) เข้า registry 2 เดือนที่ผ่านมา

ใช้กับโปรแกรมไหนได้บ้าง?

โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code

มีตัวไหนใช้แทนได้บ้าง?

ในหมวดเดียวกันมี Context7, Codebase Memory, Exa

ตัวที่ใช้แทนได้

server หมวดเดียวกันจากผู้ทำคนอื่น เรียงตามดาว

อ่านการ์ด:★ ดาว GitHubiสามเสา: รีวิว · ผลตรวจ · การใช้งานiอัปเดต = วันที่ส่งรุ่นล่าสุดเข้า registryi

Context7

โดย upstash

ส่งคู่มือการใช้ไลบรารีและเฟรมเวิร์กรุ่นล่าสุดให้ AI อ่านก่อนตอบ ช่วยให้โค้ดที่ AI เขียนไม่ใช้คำสั่งเก่าที่เลิกใช้แล้ว

บนเครื่องหรือคลาวด์★ 64,224MITอัปเดต วันนี้
ติดตั้ง

Codebase Memory

โดย DeusData

Codebase knowledge graph for AI agents — 162 languages, sub-ms queries, 99% fewer tokens.

รันบนเครื่อง★ 48,148MITอัปเดต 20 วันที่ผ่านมา
ติดตั้ง

Exa

โดย exa-labs

Connect AI agents to Exa for web search, content fetching, and multi-step research.

รันบนคลาวด์★ 5,213MITอัปเดต เดือนที่แล้ว
ติดตั้ง

README จากผู้ทำ

เปิดอ่าน README

ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ PopNx MCP ไม่ได้ตรวจหรือรับรองเนื้อหา ตัด HTML รูปภาพ และสคริปต์ออกแล้ว ลิงก์จะพาออกนอกเว็บ

🐚 limpet

small shell. long memory.

Memory for AI coding agents that goes stale when your code does. Everything your agent learns about a codebase (decisions, verified facts, failed approaches, gotchas) survives every session, anchored to the actual code it describes, and flips to stale with the reason attached the moment that code moves on. One Rust binary, one SQLite file, standard MCP, zero network calls.

the anchor lifecycle, real output: recall answers instantly, an edit flips the memory stale, a revert heals it

The failure mode that kills AI coding assistants is not forgetting; it is remembering something that is no longer true. Vector stores trust similarity, time-decay tools trust the calendar, markdown notes trust forever, so an agent that still believes last month's version of a function is not unhelpful, it is confidently wrong. limpet anchors each memory to a normalized AST hash of the code it describes: rename or move the code and the memory follows, edit it and the memory goes visibly stale with a reason, revert and it heals. Noticing its own staleness is the entire premise, and no other open memory layer does it.

⏱️ 30 seconds to running

curl -fsSL https://raw.githubusercontent.com/KSym04/limpet/main/install.sh | bash

(Windows: irm https://raw.githubusercontent.com/KSym04/limpet/main/install.ps1 | iex; full install options below.)

Restart Claude Code, type /limpet in any project, and just work:

session 1: "the scanner batch size is 50 because shared hosts kill long requests" → stored as a decision, anchored to the function that uses it

session 30, fresh context: *you:* why is the batch size 50? → *agent:* one recall, ~350 tokens, full answer. No file spelunking, no re-teaching your own codebase.

you edit that function → the memory flips to stale: body_edited everywhere it appears. Nothing ever pretends to be current when it is not.

🎯 Why limpet, in four checkable claims

  • It knows when it is wrong. Memories anchor to AST hashes, follow renames and file moves, go stale on real edits with the reason attached, and heal on revert. → the anchor lifecycle
  • It shows you what it saved. Every recall is priced against the file reads it replaced: 4.2x fewer tokens on the benchmark, and a live per-project ledger via limpet stats. → the receipts
  • It anchors the whole repository. Eleven grammars for symbol-level anchoring; every other file (templates, styles, configs) anchorable at file level. → whole repo indexed
  • It never lies by omission. Every response carries an honesty envelope: matched vs returned, what was dropped and why, how fresh the index is, how much is stale. The benchmark gate has killed limpet's own features when they crossed that line.

It is not a vector database, a code-search engine, or a call-graph oracle; it is the layer that remembers *why*, tied to the code, and tells you when the why no longer holds. → what limpet is not · design principles with the scars that earned them: PHILOSOPHY.md

🧠 Why this exists

Code indexers answer "what is where". The expensive knowledge is not in any file:

  • why the batch size is 50
  • which refactor was tried and rolled back, and what broke
  • which method names are frozen because customers hook them
  • what that weird cron job actually protects against

Agents re-derive or re-ask this every session, burning tokens, or worse, they guess. limpet gives that knowledge the same lifecycle engineers give it:

valid -> code changed -> stale (reason attached, confidence drops) -> re-verified or superseded

Three properties make it work, and nobody else combines them: anchored (AST body hashes, not line numbers or paths), honest (the envelope on every response; nothing truncates silently), evidenced (a fact can carry the command that proved it, and hands it back when the anchor goes stale).

👥 Who is this for

You arelimpet gives you
Solo dev with an AI agentThe first session spends tens of thousands of tokens learning your codebase; afterward it is one recall away. Survives /clear, compaction, new machines.
A teamadmin export writes .limpet/memory.jsonl for git; teammates import after pulling. Onboarding knowledge travels with the repo and, unlike a wiki, flags itself when the code moves on. affected shows which documented decisions a diff just put at risk.
Template-heavy stack (Rails, Laravel, Vue, any CMS theme)Every file is anchorable, so "this layout is locked to 480px" pins to the actual stylesheet and goes stale when someone edits it, exactly what symbol-only indexers cannot reach.
Open-source maintainerintent/decision memories answer "why is this weird code here" before the PR that "fixes" it lands; episode memories stop the third contributor from re-attempting the refactor that already broke twice.
Agent builderA model-agnostic memory backend behind standard MCP: one binary, zero network, inspectable SQLite. Nothing to explain to a security review.

Who should skip it: throwaway scripts, repos you touch once, teams that do not use AI agents. Memory pays off only when questions repeat.

🧰 The six tools

ToolWhat it does
recallTask description in, token-budgeted ranked memory pack out. Stale and contradicted items are always flagged, never hidden. Verified facts outrank unverified claims at equal relevance; an item without a source field is an unverified claim, not a proof.
rememberStore a memory: fact, decision, episode, insight, or intent. Anchor it to code. Attach evidence to make it verified. A near-identical body on the same anchor is refused (naming the existing id to supersede; force: true overrides), and a same-anchor memory asserting a divergent value comes back as possible_conflicts so contradictions are caught at write time. private: true keeps a memory local (recalled here, withheld from export); origin makes writes idempotent for seeding flows.
mapStructural outline of a file or symbol plus every memory attached to it. For a symbol target it also returns lineage (ancestors, descendants, callers) with each edge labeled unique/ambiguous/unresolved. Code and knowledge in one answer.
affectedWhat does my uncommitted diff touch: symbols, memories now at risk, and decisions constraining the code being edited.
verify_queueVerified facts whose anchored code changed, each with the exact command that originally proved it. Re-run the command and hand the result to admin {op:"reverify"}: the queue is no longer a dead end.
adminindex, status, forget, archive / restore, export / import (guarded), ledger / ledger_reset (the savings receipt), reverify, consolidate. Archive shelves a memory without deleting it: hidden from recall while its staleness keeps tracking the code, restored with its current truthful status, and still exported (flagged) so nothing hidden is ever lost. Export reports private_withheld so callers know how many memories stayed local. Reverify closes the verification loop: fresh evidence for a stale verified fact re-stamps its digest, re-binds its anchors to the current code, restores the full verified confidence, and returns it to active; it refuses rather than guesses when an anchor no longer resolves. Consolidate lists clusters of same-anchor, high-overlap memories worth distilling into one entry (via remember + supersedes links); it never merges anything itself.

Every response is wrapped in the honesty envelope:

{

"data": [ ... ], "meta": { "freshness": { "indexed_at": "2026-07-03T10:12:44Z", "dirty": 0 }, "completeness": { "matched": 7, "returned": 3, "omitted_reason": "budget" }, "staleness": { "stale": 1, "contradicted": 0 } } }

A recalled item also names the significant task terms found verbatim in its body ("matched": "sweep anchored", capped at three, in task order), so why an item surfaced is inspectable without re-reading it. The field is absent when no significant task term appears whole in the body: the item then reached the pack through anchor proximity, a stopword-only hit, or a stemmed or partial text match instead.

⚓ The anchor lifecycle

code change            anchor resolution         memory becomes

reformat / comments same normalized AST hash active (untouched) rename symbol body found under new FQN active, anchor follows move file body found in new file active, anchor follows edit function body hash differs at FQN stale (body_edited), conf drops delete symbol body found nowhere invalidated (kept as history) duplicate bodies multiple matches stale (ambiguous_anchor) edit anchored file file content hash differs stale (file_edited), conf drops delete anchored file file row gone invalidated (kept as history) lose SOME anchors others still resolve stale (anchor_lost), never killed move a trivial body unique match, too small stale (low_entropy), never re-pointed

A multi-anchor memory dies only when every anchor dies. Losing one anchor while others still resolve degrades it to stale:anchor_lost so the surviving knowledge stays usable. And remember refuses an anchor it cannot resolve, loudly, at write time: no memory is ever born dead.

Twins (trait impls, overloads, accessor pairs) share one FQN, so a symbol spec takes an optional @ suffix naming the exact one, spelled as the source writes it, whitespace forgiven (f@(int a, String b) and the canonicalized stored form are one spelling): the Rust trait path (impl for an inherent impl), the Go receiver type (func for a package function), the Ruby receiver (self., <<self., # for an instance method), and the parameter list for C++, Java, C#, Python and JS/TS, generic arity and JS/TS static included. An ambiguous spec is refused with the exact typeable forms listed.

symbol: "go"      → refused: matches t.T.go@A, t.T.go@B, t.T.go@impl

symbol: "go@A" → anchors to the A impl's body, and only that one symbol: "go@impl" → anchors to the inherent impl, and only that one symbol: "x@" → anchors to a twin that carries no discriminator at all (a type sharing its name with a method, say)

Rename-following is evidence-gated: a unique match on a trivial body (an empty function, a bare delegation stub, a near-empty file) is refused as follow evidence and surfaces as stale:low_entropy instead of silently re-pointing the anchor at a look-alike twin, and it heals the moment the original code returns.

Healing is confidence-neutral: going stale charges a confidence penalty once, and the pre-stale value is stored beside it, so when the reason evaporates (a branch switch back, a revert, a stash pop) the penalty is refunded in full. Decay is per reason,

ตัดมาแค่ช่วงต้น อ่านต่อใน repo

ถาม PopNx