-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Description
Describe the bug
The read_graph tool fails when it tries to read a knowledge graph from a memory.jsonl file that contains an entity with properties not defined in the official schema (name, entityType, observations). This creates an inconsistency where the server can store data that the client-side validation for read_graph will later reject, making it impossible to retrieve the stored memory.
To Reproduce
Steps to reproduce the behavior:
- Start the
@modelcontextprotocol/server-memory. - Ensure the
memory.jsonlfile contains at least one entity object with an extra, non-standard property. For example:{"name": "Test_Entity", "entityType": "test", "observations": ["Has an extra field"], "custom_id": "xyz-123"} - Use any MCP client (e.g., the VS Code extension) to execute the
read_graphtool. - Observe that the tool execution fails.
Expected behavior
The read_graph tool should successfully execute without a fatal error. It should handle entities with extra properties gracefully, ideally by ignoring the non-standard properties and returning only the schema-defined fields (name, entityType, observations) for each entity. The presence of extra data in the storage file should not prevent the core functionality of reading the graph.
Logs
The following error is returned by the client when the bug occurs:
Error: McpError: MCP error -32602: Structured content does not match the tool's output schema: data/entities/0 must NOT have additional properties
Additional context
This bug highlights a discrepancy between the data persistence logic and the data retrieval/validation logic. To resolve this, I suggest two potential approaches:
- Make the schema more flexible: Allow additional properties in the client-side schema validation for
read_graph. This would make the tool more robust. - Enforce strictness on write: Actively strip or reject any non-standard properties during entity creation (
create_entity) to ensure the integrity of thememory.jsonlfile.
Option 1 seems preferable as it adds flexibility and prevents data retrieval failures.