The search_nodes tool accepted an unbounded query string (per
modelcontextprotocol/servers#3537, official servers should constrain
string parameters). An oversized query costs an O(graph) scan per
call with no value. Cap it at 2048 chars via an exported
SearchNodesQuerySchema, and add vitest coverage for the boundary
(at-limit accepted, over-limit rejected, non-string still rejected).
Signed-off-by: fei <204683769+feiiiiii5@users.noreply.github.com>
loadGraph() trusted the persisted memory file and pushed entities and
relations without validating their fields. A corrupted or legacy entry
(e.g. an entity missing entityType, or an observation that is not a string)
would reach searchNodes and crash with "Cannot read properties of undefined
(reading 'toLowerCase')".
Validate each line against the existing EntitySchema/RelationSchema and skip
malformed entries with a warning, so the in-memory graph only ever contains
well-formed data. Malformed JSON lines are skipped as well.
Fixes#2044
delete_entities, delete_observations and delete_relations returned
success: true with a hardcoded "deleted successfully" message regardless
of what matched. An agent that mistypes an entity name is told its memory
is clean while the data is still on disk, and nothing in the response
contradicts that. addObservations throws for the same condition ten lines
above, so the file already disagreed with itself.
Staying quiet is deliberate and documented, so nothing throws and the
output schema is unchanged. The three manager methods now return what
they matched, and the handlers say so. A delete where everything is found
returns the same message it always did.
README updated: the three "Silent operation" bullets described the
absence of an error, which is still true, but read as if the response
said nothing either.
* fix(memory): expand leading ~ in MEMORY_FILE_PATH to the home directory
MCP clients pass MEMORY_FILE_PATH from JSON config, where no shell
expands a leading "~". Because path.isAbsolute("~/memory.jsonl") is
false, the value was joined onto the package directory, so the server
persisted to a literal "~" folder inside the install instead of the
user's intended location.
Add an expandHome() helper that mirrors the one already used by the
filesystem server (src/filesystem/path-utils.ts) and apply it in
ensureMemoryFilePath() before the existing absolute/relative resolution.
Absolute paths, relative paths, and a "~" not at the start are
unaffected. Adds unit tests for expandHome plus an end-to-end test
through ensureMemoryFilePath.
Addresses #1600
* test(memory): use a literal ~/ path in the tilde expansion test
path.join('~', ...) produces a backslash on Windows, which expandHome does
not match, so the test failed there.
---------
Co-authored-by: olaservo <olahungerford@gmail.com>
Fixes#4406. The memory server previously hardcoded serverInfo.version as
"0.6.3", which no longer matched published calendar versions. Resolve
package.json from both source and dist layouts so Docker and npm installs
report the installed package version.
Co-authored-by: syf2211 <syf2211@users.noreply.github.com>
Wrap the addObservations call in an async closure before asserting with
.rejects.toThrow(). This prevents Vitest's global unhandled rejection
handler from capturing the expected error before the assertion can
intercept it, eliminating the false-positive "Unhandled Errors" warning
that was failing CI.
Fixes#3073
* fix(memory): write the knowledge graph atomically
`saveGraph()` wrote the graph straight to the memory file:
await fs.writeFile(this.memoryFilePath, lines.join("\n"));
`fs.writeFile` opens the target with `'w'`, which truncates it before any
new bytes are written. If the process is interrupted between truncation
and completion — SIGKILL, container or host stop, OOM kill, power loss —
the memory file is left empty or half-written.
That file is the only persistence layer for the knowledge graph, so the
window is small but the loss is total and unrecoverable.
The fix writes to a temporary file in the same directory and renames it
over the target. `rename(2)` is atomic on POSIX filesystems: a reader
sees either the complete old file or the complete new one, never an
intermediate state. Keeping the temp file in the same directory ensures
the rename stays on one filesystem, since cross-device renames fail with
EXDEV. On failure the temp file is removed so no strays accumulate.
Tests added in `__tests__/atomic-save.test.ts`:
- the live memory file is never opened for truncating writes
- a committed graph survives a write that fails midway
- no temporary files remain after a successful write
- the temporary file is cleaned up when the rename fails
- graph contents still round-trip correctly across reloads
The first and fourth fail against the previous implementation.
Full suite: 55 passed (50 existing, 5 new). `tsc --noEmit` clean.
Fixes#4614
* fix(memory): use randomBytes for temp filename to avoid concurrent collision
---------
Co-authored-by: teddiesloco <teddiesloco@users.noreply.github.com>
The NPM_TOKEN used by publish-npm is dead (npm classic-token sunset) —
both June release attempts failed publishing with a disguised auth error
(E404 on the publish PUT) after PyPI legs succeeded. Each
@modelcontextprotocol/* package's npm trusted publisher is being bound to
this workflow (release.yml) + the release environment, so publish-npm now
authenticates via OIDC instead of a token:
- add id-token: write permission to publish-npm (required to mint the
OIDC token; contents: read added explicitly since setting permissions
drops the defaults)
- upgrade the npm CLI in the publish job (trusted publishing requires
npm >= 11.5.1; Node 22 bundles an older npm)
- drop NODE_AUTH_TOKEN from the publish step
Also touch each TypeScript server's README (add everything's missing
License section; link each package's npm page) so scripts/release.py
includes all four packages in the next npm publish matrix — they've been
stranded on npm at 2026.1.26 while PyPI advanced to 2026.6.16.
See #4463 for the rollout plan.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AViME1R9ES2UXT1uQDx1TG
* feat(memory): expose knowledge graph as MCP Resource
Register the knowledge graph as a readable MCP Resource at
memory://knowledge-graph, enabling clients to discover and read
the graph via the Resources protocol without invoking a tool.
Mutation tools (create_entities, create_relations, add_observations,
delete_entities, delete_observations, delete_relations) now emit
notifications/resources/updated so subscribed clients see live
graph changes.
Resource registration is extracted into the exported
registerKnowledgeGraphResource() function so it can be unit-tested
in isolation, mirroring the everything server's registration
pattern. New tests assert registerResource is called with the
correct kebab-case name, URI, mime type, and that the handler
returns the graph as JSON in the contents array.
Addresses PR #3323 review feedback:
- kebab-case resource name per CLAUDE.md style guide
- single-line comment per CLAUDE.md style guide
- title metadata for client discoverability
- resource update notifications after mutations
- test coverage matching everything/registrations.test.ts pattern
- README documents the new Resource
* feat(memory): support resources/subscribe for the knowledge-graph resource
PR #3323 emitted notifications/resources/updated after every mutation but
the server only advertised resources.listChanged, so resources/subscribe
returned -32601 and a spec-compliant client could never actually subscribe.
Declare resources.subscribe, add subscribe/unsubscribe request handlers that
track subscribed URIs, and only emit notifications/resources/updated when the
client has subscribed to that URI.
Co-authored-by: Lazreg Raed <lazregraed222@gmail.com>
---------
Co-authored-by: olaservo <olahungerford@gmail.com>
Real fixes (deps):
- python (git/fetch/time): idna 3.10->3.18 (GHSA-65pc), starlette
0.49.1->1.3.1 (GHSA-86qp)
- npm: vitest ^2.1.8->^4.1.8 (critical GHSA-5xrq UI server RCE). vitest 4
pulls vite 8 (rolldown, no esbuild), clearing the esbuild/vite advisories
natively. Remaining root overrides: qs>=6.15.2 (GHSA-q8mj, via express),
hono>=4.12.21 (via @modelcontextprotocol/sdk).
- npm audit: 0 vulnerabilities; all TS (313) + Python (git/fetch/time) suites
and TS builds pass.
Hardening (git_add):
- The repo already mitigates CVE-2026-27735 by using repo.git.add (the git
CLI rejects out-of-tree paths, PR #3164's fix), not repo.index.add (which
did not). Add an explicit path-boundary check in git_add as defense in
depth plus regression tests asserting the security invariant (out-of-tree
paths are never staged), guarding against a regression to repo.index.add.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Previously, `openNodes` and `searchNodes` only returned relations where
BOTH endpoints were in the result set (using `&&`). This silently
dropped all relations to/from nodes outside the set — making it
impossible to discover a node's connections without calling `read_graph`
and filtering the entire dataset client-side.
Changed the filter from `&&` to `||` so that any relation with at least
one endpoint in the result set is included. This matches the expected
graph-query semantics: when you open a node, you should see all its
edges, not just edges to other opened nodes.
Fixes#3137
Tests updated and new cases added covering:
- Outgoing relations to nodes not in the open set
- Incoming relations from nodes not in the open set
- Relations connected to a single opened node
- searchNodes returning outgoing relations to unmatched entities
Co-authored-by: Cursor <cursoragent@cursor.com>
Adds metadata required for registering servers in the MCP registry:
- NPM servers (everything, filesystem, memory, sequentialthinking):
Added mcpName and repository fields to package.json
- PyPI servers (fetch, git, time):
Added mcp-name comment to README.md
Part of #3047
Update the SDK from ^1.19.1 to ^1.23.0 in all TypeScript reference servers:
- everything
- filesystem
- memory
- sequentialthinking
Also update everything server for SDK breaking changes:
- Update zod to ^3.25.0 (zod v4 compatibility)
- Fix ToolInput/ToolOutput types to use Tool["inputSchema"] instead of
inferring from zod schemas
- Fix result.content handling to support array format
Co-authored-by: Felix Weinberger <3823880+felixweinberger@users.noreply.github.com>
* fix(memory): convert to modern TypeScript SDK APIs
Convert the memory server to use the modern McpServer API instead of
the low-level Server API.
Key changes:
- Replace Server with McpServer from @modelcontextprotocol/sdk/server/mcp.js
- Convert all 9 tools to use registerTool() instead of manual request handlers
- Create reusable Zod schemas for Entity and Relation types
- Use Zod schemas directly in inputSchema/outputSchema
- Add structuredContent to all tool responses
- Fix type literals to use 'as const' assertions
The modern API provides:
- Less boilerplate code (removed ~200 lines of schema definitions)
- Better type safety with Zod
- More declarative tool registration
- Cleaner, more maintainable code
* fix: exclude test files from TypeScript build
Add exclude for test files and vitest.config.ts to tsconfig
- Added DETECTED message when legacy memory.json file is found
- Added COMPLETED message when migration finishes successfully
- Improves visibility of backward compatibility migration process
Co-authored-by: Ola Hungerford <olaservo@users.noreply.github.com>
When no custom MEMORY_FILE_PATH is set and memory.json exists but
memory.jsonl doesn't exist, automatically migrate the old file to
the new format with proper file extension.
This ensures existing users don't lose their data when upgrading
to the version with the corrected .jsonl extension.
Co-authored-by: Ola Hungerford <olaservo@users.noreply.github.com>
The Memory MCP server uses JSONL format (JSON Lines) where each line
contains a separate JSON object, but was using a .json file extension.
This caused IDE lint errors and confusion since the file is not valid JSON.
Changes:
- Update default filename in index.ts from memory.json to memory.jsonl
- Update documentation references in README.md
- Maintain backward compatibility for existing MEMORY_FILE_PATH configs
Fixes#2361
Co-authored-by: Ola Hungerford <olaservo@users.noreply.github.com>
- Remove unnecessary explanatory note about JSON format
- JSON examples already demonstrate the correct format clearly
- Streamlines documentation to focus on essential information
- Maintains reference to official VS Code MCP documentation
The removed note was redundant since both configuration methods
use identical JSON structure shown in the examples.
- Add link to official VS Code MCP documentation in all server READMEs
- Enhances existing VS Code installation instructions with authoritative reference
- Provides users with comprehensive documentation for advanced configuration
- Complements the existing two-method approach with additional resources
Affects: everything, filesystem, git, memory, sequentialthinking
- Replace outdated 'Preferences: Open Settings (JSON)' instructions
- Add proper guidance for 'MCP: Open User Configuration' command
- Update JSON examples to remove mcp wrapper key
- Clarify user vs workspace configuration methods
- Fixes issue with outdated documentation across all servers
Affects: sequentialthinking, filesystem, memory, everything, git
