fix: Content-filter proxy + MCP servers for OpenCode on Databricks

[datasciencemonkey]

Summary

• Adds a content-filter proxy running on localhost:4000 inside the container that sanitizes requests/responses between OpenCode and Databricks AI Gateway
• Fixes multiple OpenCode bugs that cause "Bad Request" errors with Databricks Foundation Models
• Adds DeepWiki and Exa MCP server support for OpenCode
• Scope: Databricks Claude models only — Gemini and GPT/Codex have additional compatibility issues tracked separately

What the proxy fixes

OpenCode → localhost:4000 (proxy) → Databricks AI Gateway → Claude

Request-side (sanitize what OpenCode sends):

• Strip empty/whitespace-only text content blocks (OpenCode #5028)
• Strip orphaned tool_result blocks with no matching tool_use (multi-pass, cascading)
• Replace empty assistant message content with placeholder
• Strip $schema, additionalProperties from tool parameter definitions
• Strip stream_options from requests

Response-side (fix what Databricks returns):

• Remap databricks-tool-call back to real tool names
• Fix finish_reason: "stop" → "tool_calls" when tools are invoked
• SSE stream parsing with buffered tool name resolution

Root cause analysis

The bugs trace through three files in OpenCode's core:

• processor.ts#L213-L226 — creates empty text parts during streaming
• message-v2.ts#L289 — propagates them into conversation history
• transform.ts#L23-L42 — has a fix but only for @ai-sdk/anthropic, not @ai-sdk/openai-compatible

Why not PR #52's fork approach

PR #52 forks OpenCode to add a native Databricks provider. After analysis:

• Doesn't fix the root cause — no commits sanitize empty content blocks
• Fork maintenance burden — must track upstream indefinitely
• Supply chain risk — personal GitHub fork built from source at deploy time vs. community-scrutinized npm package
• Scope creep — bundles fork + spawner app + GitHub CLI + perf fixes

Valuable parts of PR #52 filed as separate issues: #53, #54, #55.

MCP servers

Added remote MCP servers to OpenCode config:

• DeepWiki — AI-powered documentation for any GitHub repository
• Exa — Web search and code context retrieval

Model support status

Model	Status	Notes
Claude Opus 4.6	✅ Working	Via content-filter proxy
Claude Sonnet 4.6	✅ Working	Via content-filter proxy
Gemini Flash/Pro	⚠️ Partial	Schema stripping helps, further compat issues likely
GPT Codex	❌ Not working	Needs Responses API handling in OpenCode SDK

Changes

File	What
content_filter_proxy.py (new)	Standalone proxy with request/response sanitization
setup_litellm.py	Setup script — kills stale proxy, starts new one, health check
setup_opencode.py	Routes through proxy, adds MCP servers, @ai-sdk/openai for GPT
app.py	Adds sequential proxy setup step before agents
requirements.txt	Unchanged (no new dependencies)
docs/plans/2026-03-11-*	Design doc with trade-off analysis

Removal path

When OpenCode fixes #5028:

1. Delete content_filter_proxy.py and setup_litellm.py
2. Revert baseURL in setup_opencode.py
3. Remove proxy step from app.py

Test plan

• Deploy to Databricks Apps
• Claude Opus — basic chat works
• Claude Opus — tool calling works
• Claude Opus — compaction works
• Proxy health check (curl http://127.0.0.1:4000/health)
• Diagnostic logging captures all requests
• Empty text blocks stripped
• Orphaned tool_results stripped
• Empty assistant content replaced with placeholder
• DeepWiki MCP works in OpenCode
• Exa MCP works in OpenCode
• Long session (10+ turns with tools)

🤖 Generated with Claude Code

[datasciencemonkey]

Root Cause: OpenCode Source Code References

The empty content block bug traces through three files in OpenCode's core:

1. Origin — processor.ts (streaming handler)

processor.ts#L213-L226 — text-start initializes a text part with text: "" and immediately persists it. If the LLM emits text-start → text-end with no deltas in between (happens between thinking blocks), an empty text part is saved to the DB.

processor.ts#L230-L245 — text-end trims but does NOT check for empty before persisting. trimEnd() on whitespace-only content produces "", which is still saved.

2. Propagation — message-v2.ts (conversation history)

message-v2.ts#L289 — toModelMessages() includes empty text parts in the conversation history sent to the LLM. It skips messages with zero parts, but a message with one empty text part passes through.

3. Partial fix exists — but only for @ai-sdk/anthropic

transform.ts#L23-L42 — normalizeMessages() already filters text: "" parts, but only for the Anthropic provider. Other providers (including @ai-sdk/openai-compatible, which we use for Databricks) receive the empty blocks.

Why the fork (PR #52) doesn't fix this

The fork adds a native Databricks provider but doesn't apply the normalizeMessages() filtering from transform.ts. The bug is in processor.ts persistence, not the provider layer.

Why LiteLLM fixes it

LiteLLM strips empty content blocks on every outbound request at the HTTP level — regardless of which provider OpenCode uses internally. It catches everything that processor.ts produces and message-v2.ts propagates.