The issue is not resolved

@NeverMore93 I've tested this fix and verified it works correctly. Here's my analysis:

Root Cause:
The validation error occurs on the client side, not the server side. When the server returns structuredContent, the MCP client validates it against the outputSchema using AJV (JSON Schema validator).

• Without .passthrough(): JSON Schema has additionalProperties: false → validation fails
• With .passthrough(): JSON Schema has additionalProperties: {} → validation passes

Test Results:
I reproduced the issue and confirmed the fix works:

# Before fix (additionalProperties: false)
Error: MCP error -32602: Structured content does not match the tool's output schema: 
data/entities/0 must NOT have additional properties

# After fix (additionalProperties: {})
SUCCESS! read_graph returns data with extra properties correctly

Could you share more details about your test environment?

• MCP SDK version (npm list @modelcontextprotocol/sdk)
• The exact error message you're seeing
• Steps to reproduce the issue

This will help identify if there's a version-specific issue or a different scenario not covered by this fix.

Thanks for the fix and the clear reproduction — this was a real issue!

The underlying bug has already been fixed, just at a different layer. Commit 8af50b9418 ("remove type from loading") on 2026-01-14 rewrote loadGraph to explicitly pick only name / entityType / observations (and from / to / relationType for relations) when building each item. That strips custom_id, metadata, and any other extras before the SDK output validator sees them, so #3144 no longer reproduces on main.

Your new test actually passes on current main without the .passthrough() change, because the stripping happens in loadGraph now. Regression tests for the same guarantee (should strip type field from entities when loading from file etc.) shipped with that commit.

Because .passthrough() would weaken the output schema — see @domdomegg's pushback on #3149 for the schema-drift reasoning — we'd rather keep the current strict z.object defaults now that the bug is fixed at the data layer.

Closing on that basis — thanks for the contribution!

(Triaged with help from Claude Code.)