[BUG] MCP not working on Claude models in antigravity?

[Xayaan]

What happened?

MCP not working on Claude models in antigravity.

I get agent terminated due to error, i tried different methods to no avail.

Steps to Reproduce

Add MCP
Try a claude model in antigravity

Component

Backend (API/Server)

Environment

No response

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[nullure]

1. MCP Server Conflicts (Most Common)
   Using Claude models (Sonnet/Opus) with certain MCP servers enabled often causes termination errors.

Fix: Disable MCP Servers.
Open Antigravity agent interface.
Click the three dots (top right).
Go to MCP Servers -> Manage MCP Servers.
Disable all servers temporarily to test, or specifically disable the Firebase MCP server if present (known conflict with tool #15).

[JaySNL]

Confirmed on my setup: MCP causes Claude models in Antigravity to terminate.

What I’m seeing

• With MCP disabled: Claude models (e.g., Sonnet/Opus) run normally.
• With MCP enabled: the agent terminates immediately with an error.

What I tried

• Toggled each MCP server on/off individually.
• Tried combinations of servers.
• Toggled all MCP servers off except one.
• Only disabling the main MCP (globally) restores Claude functionality.

Steps to reproduce

1. Enable MCP in Antigravity.
2. Select a Claude model.
3. Start the agent → it terminates with an error.
4. Disable MCP globally → Claude runs as expected.

Notes

• Behavior is consistent across multiple toggle permutations.
• Gemini isn't affected.
• No relevant logs were printed in my UI; can provide a screen recording if helpful.

[JaySNL]

I had to jump to a million hoops, but it's no longer breaking for me on Gemini OR claude, and fixed dashboard items on v1.2.3.

Title
Claude MCP crash with OpenMemory v1.2.3 due to strict JSON Schema validation; surgical schema calibration resolves cross-model compatibility

Summary
Using Claude models (Sonnet 4.5, Opus) in Antigravity with the OpenMemory MCP server caused immediate “agent terminated” crashes at connection-time schema validation. Gemini worked because it uses a permissive Draft-7 validator. We implemented a surgical schema calibration (v2.1.7) that removes specific fields rejected by Claude while preserving intelligence-enhancing fields for Gemini. Result: tools list loads and tool execution succeeds on both models; fresh Claude session loading still pending verification.

Environment

• App: Antigravity
• MCP Server: OpenMemory
• OpenMemory version: v1.2.3 (issue), v2.1.6 (partial), v2.1.7 (fix)
• Models: Claude Sonnet 4.5, Claude Opus; Gemini (MCP)
• SDK: MCP SDK with zodToJsonSchema helper
• Transport: StreamableHTTPServerTransport
• Provider: OpenRouter (Gemini also tested)

Severity
High (connection-time crash prevents tool discovery and execution for Claude users)

Steps to Reproduce

1. Start Antigravity with Claude (Sonnet 4.5 or Opus).
2. Connect to OpenMemory MCP server v1.2.3.
3. Observe initial tools/list schema validation phase.
4. Claude agent terminates with “agent terminated due to error.”

Expected Behavior

• MCP tools list schema loads without crash.
• Tools are discoverable and executable across models.

Actual Behavior

• Claude crashes at initial schema validation with “agent terminated due to error.”
• Gemini connects, loads tools, and functions normally.

Root Cause
Claude’s MCP integration (or Antigravity’s Claude handler) uses a strict whitelist JSON Schema validator that rejects non-whitelisted fields. The MCP SDK’s zodToJsonSchema emitted fields that Claude rejects:

• additionalProperties (any value)
• minLength, maxLength
• $schema
• strict, cacheControl
  Allowed fields are limited to: type, properties, required, description, enum, default, minimum, maximum, items. Gemini’s Draft-7 validator is permissive and accepts the richer schema, hence no crash.

Failed Approaches

• Runtime interception: Attempted to intercept/modify HTTP response before Claude received it; StreamableHTTPServerTransport serializes schemas inside the SDK, bypassing Express handlers.
• Build-time sed patches: Patched zod-to-json-schema during Docker build; fragile and didn’t address SDK-level generation.

Partial Attempt

• v2.1.6, low-level Server.setRequestHandler(): Gave manual control, but nested metadata objects still leaked additionalProperties: {}.

Fix (v2.1.7)
Implemented surgicalCalibrate(schema) to:

1. Remove additionalProperties entirely (any value, any level).
2. Remove $schema, strict, cacheControl.
3. Remove minLength and maxLength (string length constraints).
4. Preserve default, minimum, maximum, enum for Gemini hints.
   Applied recursively to nested objects.

Representative Post-Fix Schema (openmemory_query)

• query: type string; description only (no minLength/maxLength)
• k: type integer; minimum=1; maximum=32; default=8; description
• metadata: type object; properties: {}; description (no additionalProperties)
• required: [“query”]
• No root-level additionalProperties; no $schema

Verification
Backend functional test:

• Gemini: Memory stored (ID: 44949d48-d796-4090-8034-519dc0378b4f) – Success
• Claude (in active session): Memory stored (ID: 27f72522-e209-4f68-8bcb-0acfd3ba4300) – Success

Schema compliance:

• tools/list via curl: No additionalProperties, minLength, or $schema present

Cross-model compatibility:

• Gemini: Full functionality; parameter hints preserved
• Claude (in-session): Tool execution successful
• Claude (fresh session): Pending user verification; crash historically occurs at initial schema validation

Risks / Trade-offs

• Removing length constraints slightly reduces strictness for inputs; mitigated by preserving numeric bounds and enums.
• Fresh Claude session loading needs confirmation due to connection-time validator behavior.

References

• Function: surgicalCalibrate(schema) – recursive removal of non-whitelisted fields
• MCP SDK: zodToJsonSchema helper generates initial schema causing incompatibility
• Transport: StreamableHTTPServerTransport limits runtime interception paths

[Xayaan]

Nice one. i used a different approach to make it work but since its irrelevant now the code is updated to work. Closing this issue!