# Gemdex (npm · gemdex-mcp)

Persistent memory layer for AI coding agents: save, recall, update via Gemini plus LanceDB

- Trust score: 64/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-25

## Components

- npm · `gemdex-mcp`: 64/100 (this document), [markdown](https://verifymcp.io/servers/nikships-gemdex/gemdex-mcp.md), [page](https://verifymcp.io/servers/nikships-gemdex/gemdex-mcp)

## Channel facts

- Registry: `npm`
- Package: `gemdex-mcp`
- Version: `1.0.47`
- 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-09-25.

- **Supply Chain Security**: 89/100
  - No malware found by supply-chain analysis.
  - CVE check failed: a known high-severity CVE affects music-metadata 7.14.0, reached via gemdex-core > music-metadata. A fixed version is available.
  - No install/post-install scripts declared.
  - 68 of 219 dependencies flagged as unhealthy (1 deprecated).
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 1 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 65/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2168 tokens (~309/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "delete_memory" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 7 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.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

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

Gemdex runs locally as an npm package, launched with npx -y gemdex-mcp. 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 nikships-gemdex -- npx -y gemdex-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "nikships-gemdex": {
      "command": "npx",
      "args": [
        "-y",
        "gemdex-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "nikships-gemdex": {
      "command": "npx",
      "args": [
        "-y",
        "gemdex-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add nikships-gemdex -- npx -y gemdex-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "nikships-gemdex": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "gemdex-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add nikships-gemdex --command npx --arg -y --arg gemdex-mcp
```

### Hermes

```yaml
mcp_servers:
  nikships-gemdex:
    command: "npx"
    args: ["-y", "gemdex-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "nikships-gemdex": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "gemdex-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add nikships-gemdex -t stdio -c npx -a -y gemdex-mcp
```

### Other

```json
{
  "mcpServers": {
    "nikships-gemdex": {
      "command": "npx",
      "args": [
        "-y",
        "gemdex-mcp"
      ]
    }
  }
}
```

## 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-09-25 (score 64, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-23 (score 64)

First indexed and scored.

## MCP tools (7)

### `save_memory` (~470 tokens)

Persist a new memory to the user's global, durable memory layer.

🎯 **When to use**: proactively, as you work — you do NOT need the user to ask.
Save durable, reusable knowledge the moment you learn it: hard-won fixes and
root causes, project conventions and architecture decisions, setup/build/deploy
steps, credentials and paths the user shares, gotchas, and the rationale behind
choices. If it's likely to matter in a future session or repo, store it now
without waiting for permission. Explicit user requests ("remember that…", "save
this") are just one trigger among many. Keep memories to durable, reusable facts
— skip one-off trivia and anything easily re-derived from the current context.

Behavior: the content is chunked, embedded via the selected text provider
(Gemini or local MLX), and stored globally
(searchable from every repo and session). Returns the new memory id.

Multimodal: optionally pass `attachments` (image/audio/video/PDF) to embed
media alongside the text. Each attachment is either a local file `path`
(preferred — the server reads + encodes the bytes, so you don't emit base64) or
inline base64 `data`. Requires the gemini-embedding-2 model. Either `content`
or at least one attachment is required.

If the response includes a "⚠ similar existing memories already stored" block,
the store found near-duplicate/conflicting memories already there — read it and
consolidate with `update_memory` (or confirm with the user which should win)
rather than leaving both.

Input parameters:

- `attachments` (array): Optional media to embed. Each item is either a local file 'path' (preferred — the server reads the bytes off disk; mimeType is inferred from the extension) or inline base64 'data' with a 'mimeType'.…
- `content` (string): The memory content. A one-line fact or a long playbook — anything. Recommended; optional only when attachments are provided.
- `title` (string): Optional human-readable name. Auto-derived from content if omitted.

### `recall` (~252 tokens)

Search the user's global memory layer by natural-language query and return a
cheap ranked title index (never full bodies).

🎯 **When to use**: proactively and by default — make checking memory a reflex,
not something you wait to be told to do. Recall at the start of a task, before
solving a problem, before setting up a tool or environment, before making a
design/convention decision, and before asking the user for information they may
have already given you. A title-index recall is cheap; prefer checking first
over assuming nothing is stored.

Behavior: hybrid semantic + BM25 search, fused by relevance. Always returns up
to 10 hits as title + id only (plus a track-record line when outcome stats
exist). Most tasks end here with nothing useful — that is expected. When a
title looks clearly task-relevant, open THAT memory with `get_memory({ id })`.
Do not expect bodies from this tool.

Setting `GEMDEX_TRUST_RANKING=true` re-ranks the title index by track record
(off by default; ranking stays pure relevance until you opt in).

Input parameters:

- `query` (string, required): Natural-language description of what to recall.

### `get_memory` (~170 tokens)

Load the full content of one stored memory by id.

🎯 **When to use**: after `recall` returns a title that looks clearly relevant
to the current task — or when you already have an exact id from `save_memory`.
This is the only MCP path that returns the full parent body. Most recalls need
no follow-up; only open memories you actually intend to use.

Behavior: returns title, id, relative age, optional track-record and attachment
metadata, and the full content. Use `read_attachment` afterward if you need
attachment/transcript bytes. Opening a memory counts as a recall for the
per-client outcome ledger (feeds track-record / optional trust ranking).

Input parameters:

- `id` (string, required): The id of the memory to open (from recall or save_memory).

### `update_memory` (~541 tokens)

Revise an existing memory in place, identified by its id.

🎯 **When to use**: proactively whenever you discover a stored memory is
outdated, wrong, or duplicated — not only when the user asks
("the notarization step changed — update that memory"). If you learn a better
fact, or a `save_memory` response flags "⚠ similar existing memories already
stored", prefer correcting/consolidating the existing memory in place over
leaving stale or conflicting copies. Get the id from a prior save_memory,
recall, or get_memory result.

Two ways to change the text:
\- `edits`: targeted find-and-replace — preferred for large memories. Pass an
  array of `{ oldText, newText, replaceAll? }`; you emit only the changed
  snippets instead of resending the whole note. Each `oldText` must match
  exactly and be unique (set `replaceAll: true` to change every occurrence).
\- `content`: full replacement of the text. Use for small memories or rewrites.
\`content` and `edits` are mutually exclusive.

Behavior: re-chunks and re-embeds the resulting content under the same id.
Omitted fields are preserved — leave out `content`/`edits` to keep the prior
text, leave out `attachments` to keep the prior media (pass `attachments: []`
to clear it). Each attachment is either a local file `path` (preferred) or
inline base64 `data`. To remove a memory entirely, use `delete_memory`.

Input parameters:

- `attachments` (array): Optional media to embed. Each item is either a local file 'path' (preferred — the server reads the bytes off disk; mimeType is inferred from the extension) or inline base64 'data' with a 'mimeType'.…
- `content` (string): Full replacement text. Omit to keep the existing text. Mutually exclusive with 'edits'; prefer 'edits' for large memories.
- `edits` (array): Targeted find-and-replace edits applied to the current content — the preferred way to change part of a large memory without resending the whole note. Applied in order. Mutually exclusive with 'conten…
- `id` (string, required): The id of the memory to revise (from save_memory, recall, or get_memory).
- `title` (string): Optional new title. Omit to keep the existing title.

### `report_outcome` (~317 tokens)

Report how acting on a recalled memory went, so the memory layer learns which
memories are trustworthy.

🎯 **When to use**: right after you used a recalled memory and the outcome is
clear — `worked` (followed it and it was correct), `failed` (its information
was wrong or broken), `stale` (clearly outdated, e.g. rotated credentials or
moved paths). One call per memory actually used; do not report memories you
merely saw in results. This is meta-feedback on the memory layer itself and is
the one gemdex tool you should call without being asked, whenever a clear
outcome exists.

Recorded locally in a per-client ledger keyed by memory id (not written back
into the memory itself). With `GEMDEX_TRUST_RANKING=true` it also adjusts
future `recall` ranking — proven memories rank higher, memories that have
burned the agent rank lower.

Input parameters:

- `id` (string, required): The id of the memory you acted on (from a prior get_memory or save_memory result).
- `note` (string): Optional one-line note on what happened (e.g. "notarytool flags changed; --wait no longer accepts --timeout"). Capped at 500 characters.
- `outcome` (string, required): 'worked' — followed it and it was correct. 'failed' — its information was wrong or broken. 'stale' — clearly outdated (e.g. rotated credentials, moved paths).

### `read_attachment` (~251 tokens)

Read the bytes of an attachment on a stored memory as text (UTF-8) or base64.

🎯 **When to use**: after `get_memory` shows a memory with attachments —
especially chat digests that include a `file` attachment captioned
"Full transcript (source file)". Prefer this over opening a local path when
running in remote mode (BYOI): the bytes live in the server blob store and are
fetched over HTTP. No GEMINI_API_KEY required.

Args: `memory_id` (required), optional `attachment_id` (omit when there is
exactly one attachment, or a single transcript/`file` attachment), optional
\`max_chars` (default ~1.5M; truncates with a clear overflow note).

Input parameters:

- `attachment_id` (string): Optional attachment id. Omit when the memory has a single attachment or a single Full transcript file attachment.
- `max_chars` (number): Max characters of text/base64 to return (default 1500000). Truncates with an overflow note when exceeded.
- `memory_id` (string, required): Id of the parent memory (from save_memory, recall, or get_memory).

### `delete_memory` (~167 tokens)

Permanently delete a stored memory by id (and its attachments/blobs).

🎯 **When to use**: when a memory is obsolete, wrong beyond repair, duplicated
after consolidation, or the user explicitly asks to forget something. Prefer
\`update_memory` when the facts can be corrected in place. Get the id from a
prior save_memory, recall, or get_memory result.

Behavior: removes the memory from the backend (local LanceDB or remote BYOI
\`DELETE /v1/memories/:id`). Also clears this client's per-memory outcome
stats for that id. Irreversible via MCP — confirm with the user when unsure.

Input parameters:

- `id` (string, required): The id of the memory to delete (from save_memory, recall, or get_memory).

## Diagnostics

Captured diagnostic sections: Provenance, Vulnerabilities, Dependencies. The full working is on the page: https://verifymcp.io/servers/nikships-gemdex/gemdex-mcp#diagnostics

## Score history

- 2026-09-25: 64
- 2026-09-24: 64
- 2026-09-23: 64

## Common questions

### What is the Gemdex MCP server?

Gemdex is an MCP server listed in the public MCP registry as io.github.nikships/gemdex. Persistent memory layer for AI coding agents: save, recall, update via Gemini plus LanceDB. This page covers its npm package (gemdex-mcp).

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

Gemdex scores 64 out of 100 on VerifyMCP. We recorded 2 known advisories against it as of 25 September 2026. It declares no install or post-install scripts. 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 Gemdex MCP server expose?

Gemdex exposes 7 tools: save_memory, recall, get_memory, update_memory, report_outcome, and 2 more. Their descriptions and schemas cost roughly 2,168 tokens of context every time the server is loaded.

### Is the Gemdex MCP server still maintained?

Gemdex is still listed as active in the MCP registry. We last reached this channel on 25 September 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 Gemdex MCP server under?

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

## Links

- npm package: https://www.npmjs.com/package/gemdex-mcp
- Socket report: https://socket.dev/npm/package/gemdex-mcp
- Repository: https://github.com/nikships/gemdex
- Changelog RSS feed: https://verifymcp.io/servers/nikships-gemdex/gemdex-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/nikships-gemdex/gemdex-mcp.json
- HTML version of this page: https://verifymcp.io/servers/nikships-gemdex/gemdex-mcp