Skip to main content
ClaudeWave
LinkedParticles avatar
LinkedParticles

particles-engine-py

Ver en GitHub

Particles reference engine — corpus, LLM claim extraction, belief store, query/lint/review, CLI + HTTP + MCP. PyPI: linkedparticles

MCP ServersRegistry oficial2 estrellas0 forksPythonApache-2.0Actualizado today
ClaudeWave Trust Score
95/100
Verified
Passed
  • Open-source license (Apache-2.0)
  • Actively maintained (<30d)
  • Clear description
  • Topics declared
  • Documented (README)
Last scanned: 9/14/2026
Install in Claude Code / Claude Desktop
Method: pip / Python · linkedparticles
Claude Code CLI
claude mcp add particles-engine-py -- python -m linkedparticles
claude_desktop_config.json (Claude Desktop)
{
  "mcpServers": {
    "particles-engine-py": {
      "command": "python",
      "args": ["-m", "linkedparticles"],
      "env": {
        "ANTHROPIC_API_KEY": "<anthropic_api_key>"
      }
    }
  }
}
1. Run the command above in your terminal (Claude Code), or paste the JSON config into claude_desktop_config.json (Claude Desktop).
2. Replace any <placeholder> values with your API keys or paths.
3. Restart Claude. The MCP server and its tools appear automatically.
💡 Install first: pip install linkedparticles
Detected environment variables
ANTHROPIC_API_KEY
Casos de uso

Resumen de MCP Servers

# linkedparticles

**[linkedparticles.org](https://linkedparticles.org)** ·
**[docs.linkedparticles.org](https://docs.linkedparticles.org)** ·
[PyPI](https://pypi.org/project/linkedparticles/) ·
[Apache-2.0](https://github.com/LinkedParticles/particles-engine-py/blob/main/LICENSE)

<!-- Ownership proof for the official Model Context Protocol registry: the
     registry matches this token against the server name in server.json before
     it will accept a listing for the linkedparticles PyPI package. Keep it
     byte-identical to server.json's `name`. -->
<!-- mcp-name: org.linkedparticles/particles -->

> **Particles is shared memory for humans and AI agents.** Each particle is one
> claim, plus what you need to judge it: who said it, where, when, and how
> confident they were. Facts, opinions, and memories are all claims, recorded
> the same way as particles. Particles are not edited or deleted. Particles are
> superseded, retracted, or disputed in the open. How much to trust it is a
> perspective applied at query time, never baked into the record.

`linkedparticles` is the **Engine** of the Particles reference implementation —
the package you install to actually run a belief store. Give it documents,
pages, chat logs, or an agent's own session notes; get back claim-granularity
beliefs, each carrying calibrated confidence, an uncertainty kind, a resolved
subject, and provenance back to the exact source bytes. Ask a question and the
answer cites the beliefs it was built from. Nothing is ever overwritten, so you
can ask the store what it believed a year ago and why it stopped.

**When your agent is wrong, you can see exactly why, and fix it at the source.**

The Engine is a library first. The HTTP API, the CLI, the read-only MCP server,
and the resident daemon are all *surfaces* over it.

## Install

```bash
pip install linkedparticles
```

Python 3.11+. `linkedparticles-core` — the store-free Client layer — is pulled
in automatically.

## Sixty seconds

```bash
export ANTHROPIC_API_KEY=sk-ant-...
particles db init

# Deposit a source — file, URL, or literal text — into the append-only corpus
particles deposit https://en.wikipedia.org/wiki/Pluto

# Extract claim-granularity beliefs with confidence, subjects, and provenance
particles extract --all-pending

# Ask in natural language; the answer cites the particles behind it
particles query "Why is Pluto not a planet?"

# Health-check the store: contradictions, staleness, orphaned links
particles lint
```

Because nothing is overwritten, the store can replay its own history. `--as-of`
is the **assertion-time** lens — *what did the store believe at T, and why did
it stop* — not what was true of the world at T:

```bash
particles query "How many planets are in the Solar System?" --as-of 2000-01-01
# → the belief as it stood then, and why it no longer stands: SUPERSEDED,
#   retired 2006-08-24, superseded by "Pluto is a dwarf planet."
```

There is a clickable version of that belief history on the
[front door](https://linkedparticles.org). Step by step:
[getting started](https://docs.linkedparticles.org/user-guide/getting-started/),
then [as-of time travel](https://docs.linkedparticles.org/user-guide/as-of/).

### Wiring it into an agent

```bash
particles mcp serve                 # read-only MCP server (stdio), any MCP client
particles init claude-code          # session-start digest, session-end harvest
particles engine serve              # HTTP API, for a shared or remote engine
particles export obsidian ./vault   # also: anki, wiki, logseq, notion, graph, jsonl
```

It can also stand in for the reference memory server, and it plugs into
LangChain as a retriever and a tool set — see
[Claude Code memory](https://docs.linkedparticles.org/user-guide/claude-code/),
[swapping in for the reference memory server](https://docs.linkedparticles.org/user-guide/memory-server-swap/),
and [using from LangChain](https://docs.linkedparticles.org/user-guide/integrations/).

## Does it hold up?

Measured on **LongMemEval**, the multi-session agent-memory benchmark, with a
full-context oracle and a no-memory floor run as controls in the same harness:

| | Recall@10 | End-to-end QA |
|---|---:|---:|
| **Particles memory** | **0.940** | **0.733** |
| Full-context oracle (baseline) | — | 0.793 |
| No memory (floor) | — | 0.080 |

Method, per-question-type breakdowns, comparator memories, and the
budget-matched arm — including the arms where Particles *loses* — are on the
[benchmarks page](https://docs.linkedparticles.org/benchmarks/), with the
report JSONs of record beside them.

## Security posture

A memory layer is an *input-shaping* attack surface: it does not merely hold
data, it shapes what the agent believes and does next, so a poisoned claim is
an instruction on a delay timer. Before this code was opened we ran an
adversarial application-security audit over the whole package — the HTTP, CLI,
and MCP surfaces, the filesystem writers, the egress layer, and the build
pipeline. The verdict, verbatim: **GO-WITH-FIXES**, with **33 findings — 2
High, 7 Medium, 20 Low, 4 Info**. The ranked must-fix set merged the following
day; the last open finding closed in `v1.128.0`.

What that bought, and what it did not:

- **Prompt injection is contained, not eliminated.** Every LLM call site that
  touches attacker-controllable text keeps trusted instructions in the system
  turn and wraps the untrusted material in a per-call, 128-bit-nonce data
  fence, with structural backstops behind it — a JSON contract enforced at the
  parser, a citation-id membership gate on synthesized prose. This raises the
  bar materially. It is hardening, not immunity.
- **The model is never given tools, and no model output is executed.** No
  function-calling; nothing the model emits becomes a shell command, a SQL
  fragment, or a fetch. An injection can at worst distort *claims* — never
  trigger *actions*.
- **Outbound fetches are validated per hop.** The host is resolved, the address
  is checked against a blocklist, and the connection is made to *that vetted
  address*, re-resolved and re-validated on every redirect — closing DNS
  rebinding and redirect SSRF, not just the first lookup. The two fetches that
  run as subprocesses reach the same guarantee by pinning to addresses this
  process vetted.
- **Fail-closed auth, and no raw SQL.** The API refuses to boot on a
  non-loopback bind without a real bearer key, and the token comparison is
  constant-time. Every query in the data layer is typed ORM with bound
  parameters: no `text()`, no string-built SQL, no dynamic `ORDER BY`.
- **Local-first by default.** Loopback bind, a local SQLite file, telemetry
  off, and the MCP server as a locally-spawned stdio child rather than a
  network service. The only outbound traffic in the default posture is what you
  configured.

The real answer to the residual is epistemic rather than technical: every
particle carries its provenance, source trust is a read-time lens that
discounts a distrusted source without rewriting anything, and `lint` / `review`
turn your rulings on contradictions into a reusable trust policy. The store is
a record of *what sources said, weighted by how much you trust them* — not an
oracle — so a poisoned source is something you can see, discount, and retract
with the audit trail intact.

The limitations we ask you to read before relying on any of this — the
unauthenticated read surface, verbatim storage of whatever you deposit
(secrets included), the single-operator trust model, and the MCP write boundary
— are in
[SECURITY.md](https://github.com/LinkedParticles/particles-engine-py/blob/main/SECURITY.md).
That is also where to report a vulnerability; please report privately.

## Why Particles?

<!-- BEGIN PROJECTED: what-is (manifest: docs/projection/readme.yaml) -->
Most Retrieval-Augmented Generation systems re-derive knowledge from scratch on every query, operating over raw text chunks without any persistent record of what was learned, how confidently it was held, or where it came from. Particles takes a different approach: rather than retrieving passages, it stores discrete, citable, revisable claims — natural-language sentences paired with structured metadata for confidence, provenance, and uncertainty — so that an agent's knowledge accumulates as an auditable ledger rather than evaporating between sessions. Corpus-entry-level provenance is required at Core, meaning every belief can be traced back to the source that produced it, and the particle store itself is a derived view that can be rebuilt from the corpus by re-running extractors, giving the system both durability and reproducibility.

The Particles standard defines the particle schema, the source-corpus model, the extraction protocol, and a set of operations — deposit, extract, query, lint, review, and reindex — that together form the spine along which an agent's knowledge is built, queried, audited, and revised one belief at a time. A developer working with this loop deposits a source into the append-only corpus, extracts claim-granularity particles with resolved subjects, queries by effective-confidence ranking, lints for contradictions and staleness, and reviews inconsistencies into a reusable trust policy. Because particles carry explicit confidence and provenance, Particles can answer queries that require finding relevant claims about a subject and synthesising them with provenance intact, rather than returning a ranked list of chunks whose epistemic status is opaque.

Particles is a minimal interoperable substrate for claim-granularity agent knowledge — narrower than a formal-ontology knowledge graph such as RDF/SPARQL and more structured than augmented markdown. Anchoring every particle to a subject is what makes this precision possible: the Subject store is the standard's catalogue of real-world entities against which particles are indexed, aligning beliefs to canonical entities that can, in principle, be mapped to external on
agent-memoryai-memorybelief-storeclaim-extractioncliepistemicsfastapijson-ldknowledge-baseknowledge-graphknowledge-managementllmmcpprovenancepythonrag

Lo que la gente pregunta sobre particles-engine-py

¿Qué es LinkedParticles/particles-engine-py?

+

LinkedParticles/particles-engine-py es mcp servers para el ecosistema de Claude AI. Particles reference engine — corpus, LLM claim extraction, belief store, query/lint/review, CLI + HTTP + MCP. PyPI: linkedparticles Tiene 2 estrellas en GitHub y su última actualización registrada es del 2026-09-13.

¿Cómo se instala particles-engine-py?

+

Puedes instalar particles-engine-py clonando el repositorio (https://github.com/LinkedParticles/particles-engine-py) o siguiendo las instrucciones del README en GitHub. ClaudeWave también te ofrece bloques de instalación rápida en esta misma página.

¿Es seguro usar LinkedParticles/particles-engine-py?

+

Nuestro agente de seguridad ha analizado LinkedParticles/particles-engine-py y le ha asignado un Trust Score de 95/100 (tier: Verified). Revisa el desglose completo de comprobaciones superadas y flags en esta página.

¿Quién mantiene LinkedParticles/particles-engine-py?

+

LinkedParticles/particles-engine-py es mantenido por LinkedParticles. La última actividad registrada en GitHub es del 2026-09-13, con 0 issues abiertos.

¿Hay alternativas a particles-engine-py?

+

Sí. En ClaudeWave puedes explorar mcp servers similares en /categories/mcp, ordenados por popularidad o actividad reciente.

Despliega particles-engine-py en tu cloud

Lleva este repo a producción en minutos. Cada plataforma genera su propio entorno con variables de entorno editables.

¿Mantienes este repo? Añade un badge a tu README

Pega el badge en tu README de GitHub para mostrar que está auditado por ClaudeWave. Cada badge enlaza de vuelta a esta página y muestra el Trust Score actual.

Featured on ClaudeWave: LinkedParticles/particles-engine-py
[![Featured on ClaudeWave](https://claudewave.com/api/badge/linkedparticles-particles-engine-py)](https://claudewave.com/repo/linkedparticles-particles-engine-py)
<a href="https://claudewave.com/repo/linkedparticles-particles-engine-py"><img src="https://claudewave.com/api/badge/linkedparticles-particles-engine-py" alt="Featured on ClaudeWave: LinkedParticles/particles-engine-py" width="320" height="64" /></a>

Más MCP Servers

Alternativas a particles-engine-py