io.github.cdeust/hypermnesia-mcp
PYPI · HYPERMNESIA-MCP
Persistent memory for AI agents — 36 cited neuroscience mechanisms, local-first, hybrid retrieval.
Available components
Last scanned (7 hours ago)
Scores higher than 70% of PyPI servers
Category Memory and Knowledge
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. How we score → Why this is hard to score →
Supply Chain Security50
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 4 of 88 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to cdeust/Cortex). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 42 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability75
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 20378 tokens (~357/item across 57 items; 57 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management57
- Stability observed for 17 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage99
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 96% of tool parameters carry a description.Partial
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 58 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 −15
- Malware scan: pass → unverified ▼ security
- 4 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.
- 2 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Oct 26 +15
- Malware scan: unverified → pass ▲ security
- 30 Oct 26 +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.
- 28 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.
- 26 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.
- 24 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed pypi/hypermnesia-mcp@4.23.5
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | pypi |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | cdeust/Cortex |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/cdeust/Cortex/.github/workflows/release.yml@refs/tags/v4.23.5 |
| Rekor log index | 2920710575 |
| Predicate type | PyPI publish attestation https://docs.pypi.org/attestations/publish/v1 |
| Subject digest | sha256:944a9d48f59c1318825184e0983a4c2698c86e389334453f35534ee22624e3d5 |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 88 packages
| Packages resolved | 88 |
|---|---|
| Stale | 3 |
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
why Why (injection blame: presence-in-context) ~250
Blame path resolver: turn the ⟦rcpt:N⟧ markers visible in the current context into presence-in-context evidence — which memories each injection channel (recall, session_start, auto_recall, agent_briefing) put into the context, when, at which persisted rank and score. This is evidence of PRESENCE, never causality. Protocol: collect the ⟦rcpt:N⟧ markers that were in context BEFORE the answer being questioned; EXCLUDE the marker injected alongside the current prompt's own memory block (self-pollution guard) — then pass the ids here. To correct a wrong memory surfaced by the evidence, store a superseding memory with remember. Deterministic entry point: the /why slash command. Distinct from `get_causal_chain` (entity-graph traversal over inferred relations) and `recall` (similarity retrieval): why replays RECORDED injection receipts only.
| Name | Type | Req | Description |
|---|---|---|---|
| receipt_ids | array | yes | Receipt ids from ⟦rcpt:N⟧ markers in the current context; at most 999 per call. Pass markers present before the answer being questioned, excluding the marker attached to the current prompt. |
| Name | Type | Req | Description |
|---|---|---|---|
| count | integer | yes | Number of evidence rows returned. |
| evidence | array | yes | Flat presence-in-context evidence, one row per (receipt, injected memory) pair. Ordered by recorded facts only: emitted_at DESC, receipt id DESC, then the injection rank persisted at emission time. |
| receipts_resolved | array | – | Requested receipt ids found in the store. |
| receipts_unknown | array | – | Requested receipt ids with no stored receipt — a typo'd marker or a receipt from another store. |
| semantics | string | yes | Locked lexicon: this response proves what was PRESENT in the context, never what CAUSED an answer. |
No examples provided.
wiki_adr ~352
Create a numbered ADR (Architecture Decision Record) from structured Context/Decision/Consequences fields. Atomically: computes the next free ADR number, renders the standard template, writes wiki/adr/<NNNN>-<slug>.md under the wiki root, and registers a protected pointer memory tagged `wiki`+`adr` so the decision surfaces in `recall`. Use this whenever a non-trivial architectural choice is made — the resulting page is the single citable source of truth. Distinct from `wiki_write` (raw markdown, no auto-numbering, no template), and from `remember` (memory only, no .md file). Mutates the wiki/ tree and the memories table; refuses if the target file already exists. Latency ~50ms. Returns {path, number, title, status, created, bytes_written, root} or {error}.
| Name | Type | Req | Description |
|---|---|---|---|
| consequences | string | yes | Resulting positive and negative consequences, including what becomes easier and what becomes harder. |
| context | string | yes | The forces at play: what problem, what constraints, what alternatives exist. Markdown allowed. |
| decision | string | yes | What was decided, in active voice. State the rule, not the discussion. |
| project_root | – | – | Repository with wiki/manifest.json; filesystem-only project mode. |
| status | string | – | Lifecycle status of the ADR. Use 'proposed' during review, 'accepted' once shipped, 'superseded' when replaced (link the new ADR). |
| tags | – | – | Free-form tags for filtering and cross-referencing. |
| title | string | yes | Short imperative title of the decision. Will be slugified into the filename. 5-80 characters recommended. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_get_draft ~127
Fetch a draft + its source claims + the kind contract so the caller (LLM) can refine it, or list the pending drafts. Phase 2.3 (Path B): `wiki_synthesize` fills wiki.drafts from routed claims, this hands one to the caller, and `wiki_refine_draft` takes the prose back. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| draft_id | – | – | – |
| kind | – | – | Filter list by kind when list_pending=true. |
| limit | integer | – | – |
| list_pending | boolean | – | If true, list pending drafts instead of fetching one. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_link Wiki — link pages ~265
Add a bidirectional link between two wiki pages: write the forward relation into the `## Related` section of the source page and the inverse relation into the target page, in one idempotent operation. Use this to record dependencies, derivations, supersession chains, or free-form `see also` connections between knowledge artefacts. Distinct from `wiki_write` (authors a page, doesn't link), `wiki_compile` (publishes drafts, doesn't link), and graph-relationship tools (this writes markdown sections, not DB edges). Mutates two .md files atomically. Latency ~30ms. Returns {from_path, to_path, forward_relation, inverse_relation}.
| Name | Type | Req | Description |
|---|---|---|---|
| from_path | string | yes | Wiki-relative path of the source page (the page that owns the forward relation). Example: 'decisions/0042-use-pgvector.md'. |
| relation | string | yes | Semantic relation written on the source page; the inverse is written on the target. Pairs: depends_on/depended_on_by, derives/derived_from, implements/implemented_by, supersedes/superseded_by, plus t… |
| to_path | string | yes | Wiki-relative path of the target page (the page that receives the inverse relation). |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_list Wiki — list pages ~331
Enumerate every authored wiki page under ~/.claude/methodology/wiki/, filesystem-walked from the wiki root. Optionally restrict by kind (adr, specs, guides, reference, conventions, lessons, notes, journal, files). Two filters are applied by default and can be opted out of: (1) redirect stubs (frontmatter ``redirect_to:`` or ``redirect_id:``) are excluded — pass ``include_redirects: true`` to see them; (2) auto-generated pages (frontmatter ``provenance: auto-generated``, produced by ``codebase_analyze``) are excluded — pass ``include_auto_generated: true`` to see them. Read-only; never modifies anything. Distinct from `wiki_reindex` which generates the .generated/INDEX.md from the same enumeration, and from `wiki_read` which fetches one page's content. Latency <200ms on a 9000-page wiki. Returns {root, count, pages, redirect_count, auto_generated_count}.
| Name | Type | Req | Description |
|---|---|---|---|
| include_auto_generated | boolean | – | When true, auto-generated pages (``provenance: auto-generated``, typically from ``codebase_analyze``) are included. Default false — at ~8,700 pages these dominate listings; the default view shows hum… |
| include_redirects | boolean | – | When true, redirect stubs are included in the listing. Default false — most callers want the live pages only. |
| kind | – | – | Restrict the listing to a single page kind. Omit to list every authored page across all kinds. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_migrate Wiki — migrate FS to PG + reconcile ghosts ~353
One-shot idempotent sync of the filesystem wiki (~/.claude/methodology/wiki/) into wiki.pages / wiki.links / wiki.page_sources. Walks every PAGE_KINDS directory, upserts each page keyed on rel_path (body_hash guards no-op re-writes), re-resolves [[slug]] links, then reconciles: any wiki.pages row whose rel_path no longer exists on disk (deleted file, rename, or a wiki_purge run — which only touches the FS, never PG) is purged from wiki.pages, cascading via FK ON DELETE CASCADE to wiki.links and wiki.page_sources. The `_`-prefixed kind dirs (_kinds/_rules/_views/_bibliography/_dashboards) and the root README.md are outside the scan entirely on both phases, so they are never upserted and never purged. Defaults to dry_run=true (report the ghost rel_paths without deleting); pass dry_run=false to actually purge. Distinct from `wiki_purge` (deletes FS files that fail the classifier, never touches PG) — this tool never touches the FS, only reconciles PG to match it. A frontmatter status outside wiki.pages' DB CHECK union falls back to 'seedling' and is reported in warnings (never blocks the page write). Returns {pages_processed, pages_written, pages_unchanged, links_written, links_resolved_pass3, purge: {dry_run, ghost_count, ghost_paths, purged}, errors, error_count, warnings, warning_count}.
| Name | Type | Req | Description |
|---|---|---|---|
| dry_run | boolean | – | If true (default), report which wiki.pages rows would be purged as filesystem ghosts without deleting them. Pass false to actually delete. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_purge Wiki — purge stale ~626
Purge wiki pages that no longer earn their place. Two reject axes: (1) the page no longer passes the current classifier (`core/wiki_classifier`) — used after tightening rules or a polluting backfill; (2) the page is a stub — body is majority placeholder markers (_(to be filled)_ / _To be written._ / _(none identified)_), produced by the groomer or by template_v1 synthesis. Stubs masquerade as content but carry none. Memories remain in the store (still surface via `recall`); only the wiki markdown files are removed from disk. Distinct from `wiki_consolidate` (heat decay + lifecycle, doesn't delete based on classifier), `forget` (deletes a memory, not a wiki page), and `wiki_compile` (publishes drafts, doesn't purge). Defaults to dry-run; pass apply=true to actually delete. Latency ~200-500ms. Returns {kept, purged, purged_paths, purged_reasons, dry_run} plus the scan accounting — {wiki_pages_total, scanned, unscanned, errored, unrecognised_dirs} — so a caller can tell a full sweep from one that reached only part of the wiki. A page that failed to read counts as scanned, not unscanned: an I/O fault shows up in `errored`, never as a coverage gap.
| Name | Type | Req | Description |
|---|---|---|---|
| apply | boolean | – | If true, actually delete the files. If false (default), only report what would be purged. |
| kind | – | – | Restrict the purge to a single page-kind directory. Omit to scan all page kinds. |
| max_purges | – | – | Cap on how many pages this invocation may delete. Acts as a safety rail against a buggy classifier change wiping the whole wiki in one shot — pages beyond the cap stay on disk and surface again on th… |
| purge_classifier_rejects | boolean | – | Purge pages that the current classifier no longer admits. Set false when you only want to clean stubs without re-running the classifier. |
| purge_shallow | boolean | – | Purge pages whose body has fewer than `shallow_threshold` prose chars — typically auto-generated file-doc dumps that carry only metadata and import lists, no actual explanation. These take space and… |
| purge_stubs | boolean | – | Purge pages whose body is majority placeholder markers. The dominant noise source today — disable only when you want to inspect classifier-purges in isolation. |
| shallow_threshold | integer | – | Minimum prose-char count a page must carry to escape the shallow filter. Default 500; pages below this are flagged. |
| stub_threshold | number | – | Fraction of content lines that must be placeholder markers for stub classification. Default 0.5; lower values also match mixed-content pages. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_read Wiki — read page ~431
Fetch the raw markdown source of one wiki page by its wiki-relative path. Path resolution is sandboxed under the wiki root — absolute paths and `../` traversal are rejected at the storage layer. When the page is a redirect stub (frontmatter ``redirect_to:`` or ``redirect_id:``) the chain is followed transparently up to 5 hops; cycles and dangling targets surface as errors. Pass ``follow_redirects: false`` to read the stub itself. Page content is filesystem-only and always returned even if PostgreSQL is unreachable. As an explicit side effect, a successful read within a known Claude Code session records one deduplicated wiki.citations row (page, session) — the primary authority-earning signal driving page heat/citation_count; best-effort, never blocks or fails the read (no window session, PG down, or a page never compiled into PG all degrade to 'read succeeds, no citation'). Distinct from `wiki_list` which enumerates available pages, and from `wiki_export` which renders a page through Pandoc to PDF/DOCX/HTML. Latency <10ms. Returns {path, content, content_length, offset, root, redirect_chain} or {error}. Pages larger than the response budget come back with ``content_truncated: true`` — page via the ``offset`` argument.
| Name | Type | Req | Description |
|---|---|---|---|
| follow_redirects | boolean | – | When true (default) redirect stubs are followed transparently. When false the stub itself is returned, which is useful for admin / migration tooling. |
| offset | integer | – | Start the returned content at this character offset. Page through pages larger than the response budget: when the response carries ``content_truncated: true``, re-call with offset = previous offset +… |
| path | string | yes | Wiki-relative path of the page to read (no leading slash, no `..`). Must end in .md and resolve under the wiki root. |
| project_root | – | – | Repository with wiki/manifest.json; filesystem-only project mode. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_refine_draft ~231
Submit a refined draft (lead, sections, optional title). Updates wiki.drafts in place; records an audit memo, one row per call. The draft's confidence is left as its source claims set it (ADR-1065), so refining never moves a draft past `wiki_curate`'s approve threshold. Sections are refused unless they satisfy the kind contract returned by `wiki_get_draft`. A call carrying none of title/lead/sections/frontmatter is refused whole, and so is one whose value for any of them is empty: blanking a field is not a refinement (ADR-1068, ADR-1069). A refused call writes neither the draft nor a memo. Phase 2.3 (Path B).
| Name | Type | Req | Description |
|---|---|---|---|
| draft_id | integer | yes | – |
| frontmatter | – | – | – |
| lead | – | – | – |
| rationale | – | – | Optional explanation of what was changed and why. |
| sections | – | – | – |
| synth_model | string | – | Identifier for the refinement model/method. |
| synth_prompt | – | – | Optional copy of the refinement prompt for audit. |
| title | – | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_reindex Wiki — reindex ~252
Regenerate the wiki table of contents at <wiki_root>/.generated/INDEX.md by enumerating every authored page and grouping it by kind (adr, specs, guides, reference, conventions, lessons, notes, journal, files). Redirect stubs are excluded; auto-generated pages (``provenance: auto-generated``) are surfaced in a separate ``Auto-generated reference`` section after the human-authored content. Output is deterministic — sorted by kind then path so unchanged wikis yield byte-identical INDEX files. Authored pages are never touched. INDEX.md and the exact decision map are refreshed; project mode also updates docs/adr. Use this after bulk wiki edits, imports, or `wiki_compile` runs. Distinct from `wiki_list` (returns the listing in the response, no file write) and from `wiki_consolidate` (heat decay / staleness, not ToC rebuild). An explicit project_root isolates project publication. Latency <500ms on a 9000-page wiki. Returns {path, total_pages, by_kind, auto_generated_by_kind, redirect_count, root}.
| Name | Type | Req | Description |
|---|---|---|---|
| project_root | – | – | Repository with wiki/manifest.json; filesystem-only project mode. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_rename Wiki — rename page ~167
Move a wiki page from ``from_path`` to ``to_path`` and leave a redirect stub at the old location pointing to the new one. ``wiki_read`` follows redirect stubs transparently. Refuses to operate on pages without a stable ``id`` field (run ``scripts/wiki_backfill_ids.py`` first) or on existing redirect stubs. Returns {from_path, to_path, page_id, stub_created}.
| Name | Type | Req | Description |
|---|---|---|---|
| from_path | string | yes | Current wiki-relative path of the page. |
| overwrite_dest | boolean | – | When true, overwrite an existing destination. Default false — moves into occupied paths are an error. |
| reason | string | – | Optional free-form rationale recorded in the redirect stub's frontmatter. |
| to_path | string | yes | Destination wiki-relative path. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_verify Wiki — verify symbols ~149
Verify that code symbols cited by wiki pages still resolve in the AST (via the ai-architect-mcp-codebase MCP server, ADR-0046 Phase 2). Takes an optional path (verify one page) or no args (verify every authored page) and returns per-page verdicts: {page, symbol_refs, missing_refs, is_symbol_stale, rationale}. Requires AP enabled (CORTEX_MEMORY_AP_ENABLED=1, the default); when disabled the handler returns status=skipped and never produces a stale verdict. Read-only — never mutates wiki or memory state.
| Name | Type | Req | Description |
|---|---|---|---|
| path | – | – | Optional wiki-relative path of a single page to verify. Omit to verify the entire wiki. |
Structured output declared, but exposes no named fields.
No examples provided.
wiki_write Wiki — write page ~509
Author a new wiki page or append/replace content on an existing one (kind inferred from the first path segment: adr, specs, files, notes, lessons, conventions, guides, reference, journal). Pages live under ~/.claude/methodology/wiki/, written atomically via tmp+rename. After a successful write, registers a protected PG pointer memory tagged `wiki` so the page surfaces in `recall`. Use this for any document that should outlive the session — lessons, conventions, runbooks, anything you might link from a future ADR. Distinct from `wiki_adr` (auto-numbered ADRs from structured Context/Decision/Consequences), `wiki_compile` (publishes already-curated drafts), and `remember` (no markdown page, just a memory). Mutates the wiki/ tree, the memories table, wiki.pages (synced synchronously so the page has a resolvable id immediately), and — when `memory_ids` is passed — wiki.citations (one deduplicated row per memory actually used to author the page; how a curate_wiki job's memory cluster becomes durable, queryable provenance). Latency ~50ms. Returns {path, mode, created, bytes_written, root, citations_written} or {error}.
| Name | Type | Req | Description |
|---|---|---|---|
| content | string | yes | Raw markdown content, the final page body. Required — render it yourself (e.g. via wiki_adr for ADRs) before calling this tool; wiki_write does not render from structured fields. Markdown is preserve… |
| memory_ids | – | – | IDs of the memories you actually drew on while authoring this content — typically a subset of a `curate_wiki` job's `memory_ids`/`supporting_memory_ids` (a job proposes candidates; you may not have u… |
| mode | string | – | Write mode. 'create' refuses if the page exists; 'append' adds to the bottom; 'replace' overwrites. |
| path | string | yes | Wiki-relative path of the page (no leading slash). The first path segment determines the page kind. |
| project_root | – | – | Repository with wiki/manifest.json; filesystem-only project mode. |
| tags | – | – | Free-form tags attached to both the wiki frontmatter and the pointer memory. |
Structured output declared, but exposes no named fields.
No examples provided.
How do I install the io.github.cdeust/hypermnesia-mcp server?
io.github.cdeust/hypermnesia-mcp runs locally as a PyPI package, launched with uvx hypermnesia-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · hypermnesia-mcp
claude mcp add cdeust-hypermnesia-mcp -- uvx hypermnesia-mcp
What is the io.github.cdeust/hypermnesia-mcp server?
io.github.cdeust/hypermnesia-mcp is listed in the public MCP registry as io.github.cdeust/hypermnesia-mcp. Persistent memory for AI agents, 36 cited neuroscience mechanisms, local-first, hybrid retrieval. This page covers its PyPI package (hypermnesia-mcp).
Is the io.github.cdeust/hypermnesia-mcp server safe to use?
io.github.cdeust/hypermnesia-mcp scores 74 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 io.github.cdeust/hypermnesia-mcp server expose?
io.github.cdeust/hypermnesia-mcp exposes 57 tools: query_methodology, detect_domain, rebuild_profiles, list_domains, record_session_end, and 52 more. Their descriptions and schemas cost roughly 20,203 tokens of context every time the server is loaded.
Is the io.github.cdeust/hypermnesia-mcp server still maintained?
io.github.cdeust/hypermnesia-mcp 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 io.github.cdeust/hypermnesia-mcp server under?
io.github.cdeust/hypermnesia-mcp declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.