fix(memory): add 'type' to schemas and use passthrough for Gemini CLI…

[ericnjurio]

Title
fix(memory): enhance schema compatibility for strict JSON validators (like Gemini CLI)

Description
This PR updates the memory server's Zod schemas to improve compatibility with MCP clients that enforce strict JSON schema validation, such as the Google Gemini CLI.

The changes include:

1. Formally declaring the optional type property in EntitySchema and RelationSchema.
2. Enabling .passthrough() on these schemas to allow for internal or future properties without breaking strict validation.

Server Details

• Server: memory
• Changes to: tools (Output schemas for read_graph, search_nodes, and open_nodes)

Motivation and Context
Strict MCP clients like the Gemini CLI perform rigorous validation on tool outputs. The memory server includes a type field in its internal JSONL storage which is subsequently returned in tool outputs. Since this field was not declared in the tool's output schema, Gemini CLI rejected the response with an "additional properties not allowed" error (code -32602).

By declaring the type field and using .passthrough(), we ensure the server remains robust and compatible with both permissive and strict clients.

How Has This Been Tested?
Tested locally using google-gemini-cli:

• Verified that read_graph no longer triggers validation errors and returns the full graph.
• Verified that search_nodes and open_nodes successfully return structured content.
• Confirmed that data remains intact in the memory.jsonl file.

Breaking Changes

• No. This change is additive and increases tolerance for existing data structures.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the [MCP Protocol Documentation (https://modelcontextprotocol.io)
• My changes follows MCP security best practices
• I have updated the server's README accordingly (N/A - no user-facing config changes)
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally (Need to run npm test)
• I have added appropriate error handling
• I have documented all environment variables and configuration options (N/A)

Additional context
The type discriminator is essential for the server's internal logic when parsing the JSONL file. Formalizing its presence in the communication schema resolves the "hidden property" conflict with strict validators.

[diffray-bot]

Changes Summary

This PR fixes a schema validation compatibility issue with the memory server by adding the optional 'type' property to EntitySchema and RelationSchema, and enabling .passthrough() on both schemas. This resolves 'additional properties not allowed' errors when strict JSON validators like Gemini CLI validate tool outputs that include the internal 'type' discriminator field.

Type: bugfix

Components Affected: memory-server, EntitySchema, RelationSchema, Entity interface, Relation interface

Architecture Impact

• Coupling: The schemas now explicitly declare the internal 'type' field that was already present in the JSONL storage format, improving consistency between storage format and API contract

Risk Areas: The .passthrough() modifier allows any additional properties through validation, which could mask future schema drift or unexpected data, Input validation now accepts 'type' field from external clients, though it's marked as optional

Suggestions

• Consider if .passthrough() is too permissive - an alternative would be to only declare the 'type' field without passthrough, maintaining stricter validation on other properties
• Consider adding a test case that validates the schema works correctly with both permissive and strict validators

_{Full review in progress... | Powered by diffray}