# Particles (pypi · linkedparticles)

An append-only ledger of sourced, dated, confidence-scored claims your agent cites and you audit

- Trust score: 69/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- pypi · `linkedparticles`: 69/100 (this document), [markdown](https://verifymcp.io/servers/org-linkedparticles-particles/linkedparticles.md), [page](https://verifymcp.io/servers/org-linkedparticles-particles/linkedparticles)

## Channel facts

- Registry: `pypi`
- Package: `linkedparticles`
- Version: `1.224.6`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 50/100
  - Malware scan not yet available for this package.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs hatchling.build at install time, a recognised build step with no custom scripting around it.
  - 8 of 113 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to LinkedParticles/particles-engine-py).
  - Clear OSI-approved license (Apache-2.0).
  - Actively maintained (last published 3 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 56/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 5143 tokens (~321/item across 16 items; 16 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 57/100
  - Stability observed for 17 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 16 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 17 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Particles MCP server?

Particles runs locally as a PyPI package, launched with uvx linkedparticles. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add org-linkedparticles-particles -- uvx linkedparticles
```

### Cursor

```json
{
  "mcpServers": {
    "org-linkedparticles-particles": {
      "command": "uvx",
      "args": [
        "linkedparticles"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "org-linkedparticles-particles": {
      "command": "uvx",
      "args": [
        "linkedparticles"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add org-linkedparticles-particles -- uvx linkedparticles
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "org-linkedparticles-particles": {
      "type": "local",
      "command": [
        "uvx",
        "linkedparticles"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add org-linkedparticles-particles --command uvx --arg linkedparticles
```

### Hermes

```yaml
mcp_servers:
  org-linkedparticles-particles:
    command: "uvx"
    args: ["linkedparticles"]
```

### Netclaw

```json
{
  "McpServers": {
    "org-linkedparticles-particles": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "linkedparticles"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add org-linkedparticles-particles -t stdio -c uvx -a linkedparticles
```

### Other

```json
{
  "mcpServers": {
    "org-linkedparticles-particles": {
      "command": "uvx",
      "args": [
        "linkedparticles"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 69, −14)

- [security regression] Malware scan: pass → unverified

### 2026-11-04 (score 83, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-11-03 (score 68, +1)

No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-02 (score 67, −15)

- [security regression] Malware scan: pass → unverified
- [functional] Package version: 1.210.2 → 1.224.6

### 2026-11-01 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-31 (score 81, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-10-30 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-29 (score 65, −15)

- [security regression] Malware scan: pass → unverified

## MCP tools (16)

### `query` (~1478 tokens)

Run a tag-aware semantic query against the particle store.

Args:
    question: Natural-language question. Optional since: omit it
        and set structural claim filters (or an aggregate / the predicate
        listing) for the deterministic modes — no embedding, no LLM call.
    tags: Subtree-expanded tag filters, repeatable.
    subject_id: Restrict to particles about this subject.
    min_confidence: Minimum confidence value (0.0–1.0).
    top_k: Number of particles to retrieve (1–200).
    audience: "GENERAL" | "EXPERT" | "REGULATORY".
    summary: When ``True``, each hit in ``particles`` is reduced to
        ``{id, content, confidence, effective_confidence,
        subject_ids}`` — provenance, tags, properties, and
        embeddings are dropped. The NL ``answer`` string and
        coverage gaps are unchanged. Use this when the agent only
        needs to surface the answer and pick particles to
        ``particle_show`` later. Default ``False`` preserves the
        full ``QueryResponse`` shape for backward compatibility.
    as_of: ISO-8601 past instant (a bare date means start of that
        day, UTC): answer what the store believed at T.
        Retired hits carry an ``as_of_notes`` entry (current status,
        retirement instant + basis, and the superseding belief);
        ``as_of_excluded_undatable`` discloses retirements the store
        cannot date. A future instant is rejected.
    during_start: With ``during_end``, a window of world time (ISO-8601
        dates, inclusive; either may be omitted for an open end): answer
        about what began in, or was in force during, that period.
        The window prefilters the candidate set before ranking;
        with no question it returns the claims in date order, each with a
        ``window_hits`` reading (``BEGAN``, ``IN_FORCE``, ``HELD_AT``,
        ``WITHIN``). A retired claim is admitted for the period it held,
        marked with its retirement and its close. Reads ``valid_from``;
        ``…

Input parameters:

- `all_projects` (boolean)
- `as_of`
- `audience` (string)
- `count` (boolean)
- `during_end`
- `during_start`
- `grounded`
- `group_by`
- `list_predicates` (boolean)
- `min_confidence` (number)
- `min_effective_confidence`
- `object_contains`
- `object_eq`
- `object_gt`
- `object_lt`
- `on`
- `predicate`
- `question`
- `subject_id`
- `summary` (boolean)
- `tags`
- `top_k` (integer)

### `particle_show` (~159 tokens)

Show one particle with its provenance, subjects, and tags.

Args:
    particle_id: Full UUID or unambiguous prefix (≥ 8 chars).

Returns:
    Dict with ``particle`` (Pydantic JSON), ``subjects`` (list of
    ``{id, canonical_name}``), and ``provenance`` (list of
    ``{type, corpus_entry_id, uri_r, source_type, snapshot_id}``).
    When the source now states the claim in other words, ``restated_as``
    holds that wording and its snapshot; the claim's
    ``content`` keeps its first wording. Raises if the prefix matches zero
    or multiple particles.

Input parameters:

- `particle_id` (string, required)

### `particles_list` (~520 tokens)

List particles, optionally filtered by status or subject.

Lightweight alternative to ``query`` and ``lint`` when an agent
just needs the IDs of particles in a particular state — e.g. the
open INCONSISTENCY queue, RETRACTED particles for cleanup, or
every ACTIVE particle linked to a subject. Embeddings are never
included; responses are designed to stay within MCP tool-result
size caps.

Args:
    status: Optional status filter — one of
        ``ACTIVE``, ``SUPERSEDED``, ``RETRACTED``,
        ``PROVENANCE_STALE``, ``INCONSISTENCY``. Unset returns
        particles in any status.
    subject_id: Optional subject: a full ID, an ID prefix,
        or a name or alias, resolved as ``subjects_show`` resolves it.
        When set, only particles linked to that subject via the
        ``particle_subjects`` join table are returned, and the result
        echoes the resolved ``subject_id``. A reference that matches no
        subject, or more than one, raises.
    limit: Maximum particles to return (default 50). Must be > 0.
    offset: Number of particles to skip before returning results
        (default 0). Combine with ``limit`` to page through the
        full set.
    all_projects: On a server bound to one project, read the whole
        store instead of that project's view. The result says so. No effect
        on an unbound server.

Returns:
    Dict with ``particles`` — a list of summary dicts containing
    ``id``, ``status``, ``content``, ``confidence``,
    ``subject_ids``, ``asserted_at``, and ``status_reason``. Each
    entry's ``contested`` key is the id of an open INCONSISTENCY
    referencing it, else null; ``contested_bases``
    rides beside it with the fired basis labels —
    composed by the same composer the ``query`` tool uses, so all
    three bases (stance / divergence / inconsistency) are evaluated
    and the two surfaces on one server always agree. Plus
    ``limit``/``offset`` echoed back so the agent can drive
    pagination. Embeddings are inte…

Input parameters:

- `all_projects` (boolean)
- `limit` (integer)
- `offset` (integer)
- `status`
- `subject_id`

### `particle_search` (~171 tokens)

List particles sharing a context fingerprint.

Args:
    fingerprint: Full 64-char SHA-256 hex or a prefix (≥ 8 chars).
    limit: Maximum particles to return (default 50, capped at 200 to
        keep responses within MCP per-tool-result token caps —
        fingerprint matches share full ``content`` strings).
    all_projects: On a server bound to one project, read the whole
        store instead of that project's view. The result says so. No effect
        on an unbound server.

Returns:
    Dict with ``fingerprint`` (the queried value) and ``particles``
    (list of ``{id, status, content}`` summaries).

Input parameters:

- `all_projects` (boolean)
- `fingerprint` (string, required)
- `limit` (integer)

### `subjects_list` (~187 tokens)

List subjects in the knowledge graph (alphabetical by canonical_name).

Paginated to keep responses within an MCP-client-friendly size — the
full subject set can easily exceed per-tool-result token caps.

Args:
    limit: Maximum subjects to return (default 50).
    offset: Number of subjects to skip before returning results
        (default 0). Combine with ``limit`` to page through the
        full set.
    order: ``"name"`` (alphabetical, default) or ``"degree"`` —
        most-connected first, by descending count of ACTIVE
        particles linked to each subject (name tie-break). Use
        ``"degree"`` to find a store's hub subjects, e.g. as a
        ``graph_view`` starting scope.

Input parameters:

- `limit` (integer)
- `offset` (integer)
- `order` (string)

Output parameters:

- `result` (array)

### `subjects_search` (~144 tokens)

Substring search over subject names and aliases (case-insensitive).

Args:
    query: Substring to match against ``canonical_name`` or any recorded
        alias, so "speaker" finds a subject whose alias is "the speaker".
    limit: Maximum subjects to return (default 50). A generic
        substring like "the" can match thousands of subjects, so
        this caps the page size.
    offset: Number of matches to skip before returning results
        (default 0). Results are alphabetical by canonical_name
        so pagination is stable.

Input parameters:

- `limit` (integer)
- `offset` (integer)
- `query` (string, required)

Output parameters:

- `result` (array)

### `subjects_show` (~264 tokens)

Show one subject with the particle IDs linked to it.

Args:
    subject_id: A full UUID, an unambiguous prefix (≥ 8 chars), or a
        name or alias, matched case-insensitively and exactly. A
        reference that matches more than one subject (a prefix shared
        by several IDs, a name two subjects share, or a string that is
        both a prefix and a name) raises with the candidates named. A
        remote engine resolves IDs and prefixes only.
    particle_id_limit: Maximum particle IDs to include in
        ``particle_ids`` (default 100). For hot subjects the full
        list can blow the per-tool-result token cap; use
        ``particles_list(subject_id=…, limit=…, offset=…)`` for
        the full set when ``particle_count > particle_id_limit``.

Returns:
    Dict with ``subject`` (Pydantic JSON), ``particle_ids`` (capped
    at ``particle_id_limit``, ordered by id for stable pagination),
    and ``particle_count`` — the true total of linked particles,
    so callers can detect when the list was truncated.

Input parameters:

- `particle_id_limit` (integer)
- `subject_id` (string, required)

### `list_taxonomies` (~112 tokens)

List every taxonomy + its full tag tree.

Args:
    limit: Maximum taxonomies to return (default 50). Each
        taxonomy embeds its full tag tree, so even a handful of
        large taxonomies can push the response past the
        per-tool-result token cap.
    offset: Number of taxonomies to skip before returning results
        (default 0). Results are ordered by name so pagination is
        stable.

Input parameters:

- `limit` (integer)
- `offset` (integer)

Output parameters:

- `result` (array)

### `list_corpus_entries` (~71 tokens)

List recent corpus entries (most-recently-deposited first).

Args:
    limit: Maximum entries to return (default 50).
    source_type: Optional filter (e.g. ``"WIKIDATA_API"``).

Input parameters:

- `limit` (integer)
- `source_type`

Output parameters:

- `result` (array)

### `lint` (~326 tokens)

Run structural lint checks over the particle store (no fixes, no LLM).

The MCP surface is read-only, so ``--fix`` is forced off and the
LLM-assisted semantic checks are disabled — agents read findings
and surface them to the operator, who decides whether to act.

Args:
    category: Optional ``finding_type`` filter (e.g. ``STALENESS``,
        ``PHANTOM_SUBJECT``, ``WIKIDATA_LINK_MISMATCH``). When set,
        only findings of that kind are returned; ``summary`` is
        always the full counts dict and reflects every category
        actually emitted by this run.
    summary_only: When ``True``, drop the ``findings`` list and
        return only the ``summary`` counts dict (plus ``run_at``).
        Useful when the agent only needs to know what *kinds* of
        problems exist before drilling in with ``category``.
    limit: Maximum findings to include after filtering (default
        100). Hard cap to keep the response under per-tool-result
        size limits even when many findings of one category exist.
        A ``truncated`` flag is added when the cap fires.

Returns:
    ``{run_at, findings, summary}`` matching the ``LintReport``
    schema, optionally with ``truncated: True`` and (when
    ``summary_only``) without the ``findings`` key.

Input parameters:

- `category`
- `limit` (integer)
- `summary_only` (boolean)

### `quality_report` (~106 tokens)

Return the extraction-quality dashboard snapshot.

Particle counts by status / calibration_source / schema_version,
plus the structural-mix percentages, the store's recorded LLM spend
(``llm_spend``), and the curation queue's precision over the default
window (``curation_precision``: per card kind, the cards acted on,
dismissed, snoozed and untouched, with the denominator). Computed
entirely from live DB queries — no LLM involvement.

### `links_suggest` (~230 tokens)

Propose co-evidential candidate pairs within Subjects (read-only).

Within each Subject, ACTIVE particles whose embeddings exceed the
similarity threshold and are not already linked CO_EVIDENTIAL are
surfaced as candidate pairs for operator review. No LLM call, no
mutation — this is the ``REPORT`` mode of ``particles links suggest``.

Args:
    subject_id: Restrict to one Subject. ``None`` scans every
        Subject — prefer passing a ``subject_id`` to keep results focused.
    threshold: Cosine-similarity floor (0.0–1.0). Defaults to
        ``links_suggest.candidate_threshold`` when omitted.
    limit: Maximum candidate pairs to include across all clusters
        (default 100). A ``truncated`` flag is added when the cap fires.

Returns:
    ``{run_at, mode, clusters, total_candidates, warnings}`` matching the
    ``SuggestReport`` schema, optionally with ``truncated: True``.

Input parameters:

- `limit` (integer)
- `subject_id`
- `threshold`

### `corpus_links_suggest` (~171 tokens)

Rank undeposited URLs the corpus frequently cites (read-only).

Surfaces primary sources the corpus leans on but has never deposited —
"hearsay vs. primary source" gaps — ranked by trust-weighted distinct-source
diversity × recency. Read-only: the ``dismiss`` half of the
workflow lives on the CLI / HTTP API.

Args:
    limit: Maximum suggestions to return. Defaults to
        ``citation_signal.rank_cap`` when omitted.
    min_sources: Minimum distinct citing sources required to surface a URL.
        Defaults to ``citation_signal.min_distinct_sources`` when omitted.

Returns:
    ``{suggestions, total_candidates, capped}`` matching the
    ``DepositSuggestReport`` schema.

Input parameters:

- `limit`
- `min_sources`

### `events_list` (~156 tokens)

List operator events, newest first, optionally filtered.

Args:
    particle: Only events touching this particle id.
    subject: Only events touching this subject id.
    corpus_entry: Only events touching this corpus entry id.
        (At most one of ``particle`` / ``subject`` / ``corpus_entry``.)
    event_type: Only events of this type, e.g. ``SOURCE_RETRACTED``,
        ``SUBJECTS_SPLIT``, ``TRUST_CHANGED``, ``REVIEW_RESOLVED``.
    limit: Maximum events to return (default 50).

Input parameters:

- `corpus_entry`
- `event_type`
- `limit` (integer)
- `particle`
- `subject`

Output parameters:

- `result` (array)

### `event_show` (~41 tokens)

Show one operator event in full — header, refs, and payload.

Args:
    event_id: The event's id.

Input parameters:

- `event_id` (string, required)

### `graph_view` (~741 tokens)

Render one scoped epistemic subgraph of the particle store.

Scope is mandatory — pass exactly one of ``subject_id`` / ``query`` /
\``inconsistency_id`` / ``manifest``+``section`` (a whole-store render
does not exist; the anti-hairball invariant). Every
epistemic quantity in the result (effective confidence, contested
badges, as-of visibility, utility evidence) is computed at render time
by the engine and never stored.

Args:
    subject_id: Neighbourhood scope — this Subject, its particles, and
        subjects reachable within ``hops`` via multi-subject particles.
        Accepts a subject id or an exact (case-insensitive) canonical
        name / alias; the render's ``scope_ref`` is the resolved id.
    query: Retrieval-set scope — the top-K hits of the existing query
        ranking rendered as their subjects plus the hit particles
        ("the picture of the knowledge the agent consulted").
    inconsistency_id: Evidence scope — a contradiction's
        picture: the INCONSISTENCY particle as the anchor, its two
        disputant beliefs shown with their true statuses (the
        quarantined side included), their subjects and sources. Accepts
        a full particle id or a unique prefix (a contested badge's
        ``inconsistency_id`` is the usual source).
    manifest: With ``section``, projection scope — an
        manifest section's deterministic selection rendered as
        a graph. The manifest is a relative name under the engine's
        ``graph.manifest_root``; with that unset the scope is refused.
    section: The manifest section's ``region`` id, or its exact
        (case-insensitive) title.
    hops: Neighbourhood radius for subject scope (clamped to
        ``graph.max_hops``).
    history: Also include retired supersession-chain ancestors, rendered
        as ghosts.
    as_of: ISO-8601 past instant (a bare date means start of that day,
        UTC): render the graph as believed at T. A future
        instant is rejected.
    max_nodes: Per-c…

Input parameters:

- `all_projects` (boolean)
- `as_of`
- `history` (boolean)
- `hops` (integer)
- `inconsistency_id`
- `manifest`
- `max_nodes`
- `query`
- `section`
- `store` (string)
- `subject_id`

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/org-linkedparticles-particles/linkedparticles#diagnostics

## Score history

- 2026-11-05: 69
- 2026-11-04: 83
- 2026-11-03: 68
- 2026-11-02: 67
- 2026-11-01: 82
- 2026-10-31: 81
- 2026-10-30: 66
- 2026-10-29: 65
- 2026-10-28: 80
- 2026-10-27: 80
- 2026-10-26: 79
- 2026-10-25: 79
- 2026-10-24: 63
- 2026-10-23: 78
- 2026-10-22: 62
- 2026-10-21: 62
- 2026-10-20: 61
- 2026-10-19: 61
- 2026-10-18: 50
- 2026-10-17: 35
- 2026-10-16: 35
- 2026-10-15: 35
- 2026-10-14: 35
- 2026-10-13: 50
- 2026-10-12: 24
- 2026-10-07: 45
- 2026-10-05: 50
- 2026-10-04: 50
- 2026-10-03: 35
- 2026-10-02: 35

## Common questions

### What is the Particles MCP server?

Particles is an MCP server listed in the public MCP registry as org.linkedparticles/particles. An append-only ledger of sourced, dated, confidence-scored claims your agent cites and you audit. This page covers its PyPI package (linkedparticles).

### Is the Particles MCP server safe to use?

Particles scores 69 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Particles MCP server expose?

Particles exposes 16 tools: query, particle_show, particles_list, particle_search, subjects_list, and 11 more. Their descriptions and schemas cost roughly 4,877 tokens of context every time the server is loaded.

### Is the Particles MCP server still maintained?

Particles is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Particles MCP server under?

Particles declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/linkedparticles/
- Socket report: https://socket.dev/pypi/package/linkedparticles
- Repository: https://github.com/LinkedParticles/particles-engine-py
- Website: https://docs.linkedparticles.org/cli/#mcp-server
- Changelog RSS feed: https://verifymcp.io/servers/org-linkedparticles-particles/linkedparticles.xml
- Changelog JSON feed: https://verifymcp.io/servers/org-linkedparticles-particles/linkedparticles.json
- HTML version of this page: https://verifymcp.io/servers/org-linkedparticles-particles/linkedparticles