🐛 MCP Tools Failing: TypeError on output.output.toLowerCase() in v1.1.50 #9050

Closed
opened 2026-02-16 18:11:31 -05:00 by yindo · 4 comments
Owner

Originally created by @roshitx on GitHub (Feb 11, 2026).

Originally assigned to: @thdxr on GitHub.

Bug Description

All MCP (Model Context Protocol) tool calls are failing with a TypeError in OpenCode v1.1.50. This affects all MCP servers including Laravel Boost, Exa, Context7, and other MCP integrations.

Error Message:

TypeError: undefined is not an object (evaluating 'output.output.toLowerCase')

Environment

  • OpenCode Version: 1.1.50 (latest stable)
  • Platform: macOS (darwin-arm64)
  • Installation Method: Homebrew
  • Node Version: v24.1.0

Steps to Reproduce

  1. Install OpenCode v1.1.50 via Homebrew
  2. Configure any MCP server (e.g., Laravel Boost MCP)
  3. Attempt to call any MCP tool

Example with Laravel Boost:

laravel-boost_search-docs({
  queries: ["migration", "database migration"]
})

Example with Exa:

exa_web_search_exa({
  query: "OpenCode documentation",
  numResults: 5
})

Expected Behavior

MCP tools should execute successfully and return results.

Actual Behavior

All MCP tool calls fail immediately with:

TypeError: undefined is not an object (evaluating 'output.output.toLowerCase')

Root Cause Analysis

The client-side MCP response parser expects a nested structure:

response.output.output.toLowerCase()

However, MCP servers are returning a flat structure:

response.output  // No nested .output property

This is confirmed by direct tool execution working correctly:

# Direct execution works (bypasses OpenCode client parser)
php artisan boost:execute-tool 'Laravel\Boost\Mcp\Tools\SearchDocs' 'base64params'
# Returns: {"isError":false,"content":[{"type":"text","text":"..."}]}

The backend MCP server responses are correct - the bug is in OpenCode's client-side parsing layer.

Affected Components

  • Laravel Boost MCP - All tools fail
  • Exa MCP - All tools fail
  • Context7 MCP - All tools fail
  • grep.app MCP - All tools fail
  • All other MCP integrations - Likely affected

Workaround

For Laravel Boost users, direct tool execution via bash:

php artisan boost:execute-tool 'ToolClassName' 'base64_encoded_params'

Additional Context

  • MCP server logs show successful tool execution
  • Error occurs during response parsing in OpenCode client
  • Binary is compiled (Mach-O), cannot patch directly
  • Logs location: ~/.local/share/opencode/log/

Verification

Confirmed with:

opencode --version  # 1.1.50
opencode debug config  # Shows MCP servers configured correctly

MCP servers initialize successfully but all tool invocations fail at the response parsing stage.

Suggested Fix

Update MCP response parser to handle flat output structure:

// Current (broken)
output.output.toLowerCase()

// Suggested fix
(output?.output || output)?.toLowerCase?.()

Or properly validate MCP response schema before accessing nested properties.

Originally created by @roshitx on GitHub (Feb 11, 2026). Originally assigned to: @thdxr on GitHub. ## Bug Description All MCP (Model Context Protocol) tool calls are failing with a TypeError in OpenCode v1.1.50. This affects **all MCP servers** including Laravel Boost, Exa, Context7, and other MCP integrations. **Error Message:** ``` TypeError: undefined is not an object (evaluating 'output.output.toLowerCase') ``` ## Environment - **OpenCode Version:** 1.1.50 (latest stable) - **Platform:** macOS (darwin-arm64) - **Installation Method:** Homebrew - **Node Version:** v24.1.0 ## Steps to Reproduce 1. Install OpenCode v1.1.50 via Homebrew 2. Configure any MCP server (e.g., Laravel Boost MCP) 3. Attempt to call any MCP tool **Example with Laravel Boost:** ```typescript laravel-boost_search-docs({ queries: ["migration", "database migration"] }) ``` **Example with Exa:** ```typescript exa_web_search_exa({ query: "OpenCode documentation", numResults: 5 }) ``` ## Expected Behavior MCP tools should execute successfully and return results. ## Actual Behavior All MCP tool calls fail immediately with: ``` TypeError: undefined is not an object (evaluating 'output.output.toLowerCase') ``` ## Root Cause Analysis The client-side MCP response parser expects a nested structure: ```javascript response.output.output.toLowerCase() ``` However, MCP servers are returning a flat structure: ```javascript response.output // No nested .output property ``` This is confirmed by direct tool execution working correctly: ```bash # Direct execution works (bypasses OpenCode client parser) php artisan boost:execute-tool 'Laravel\Boost\Mcp\Tools\SearchDocs' 'base64params' # Returns: {"isError":false,"content":[{"type":"text","text":"..."}]} ``` The backend MCP server responses are correct - the bug is in OpenCode's client-side parsing layer. ## Affected Components - ✅ **Laravel Boost MCP** - All tools fail - ✅ **Exa MCP** - All tools fail - ✅ **Context7 MCP** - All tools fail - ✅ **grep.app MCP** - All tools fail - ✅ **All other MCP integrations** - Likely affected ## Workaround For Laravel Boost users, direct tool execution via bash: ```bash php artisan boost:execute-tool 'ToolClassName' 'base64_encoded_params' ``` ## Additional Context - MCP server logs show successful tool execution - Error occurs during response parsing in OpenCode client - Binary is compiled (Mach-O), cannot patch directly - Logs location: `~/.local/share/opencode/log/` ## Verification Confirmed with: ```bash opencode --version # 1.1.50 opencode debug config # Shows MCP servers configured correctly ``` MCP servers initialize successfully but all tool invocations fail at the response parsing stage. ## Suggested Fix Update MCP response parser to handle flat `output` structure: ```javascript // Current (broken) output.output.toLowerCase() // Suggested fix (output?.output || output)?.toLowerCase?.() ``` Or properly validate MCP response schema before accessing nested properties.
yindo closed this issue 2026-02-16 18:11:31 -05:00
Author
Owner

@roshitx commented on GitHub (Feb 11, 2026):

Note: Duplicate of #12987 (Kubernetes MCP issue)

This bug affects ALL MCP servers, not just specific integrations. See my comment on #12987 for comprehensive details.

Keeping this issue open for additional Laravel Boost workaround documentation.

@roshitx commented on GitHub (Feb 11, 2026): **Note:** Duplicate of #12987 (Kubernetes MCP issue) This bug affects ALL MCP servers, not just specific integrations. See my comment on #12987 for comprehensive details. Keeping this issue open for additional Laravel Boost workaround documentation.
Author
Owner

@github-actions[bot] commented on GitHub (Feb 11, 2026):

This issue appears to be a duplicate of #12987, which reports the identical TypeError with MCP tool calls. Both issues involve the same root cause: OpenCode's client-side MCP response parser expecting a nested output.output structure when the MCP servers are correctly returning a flat output structure.

Please check #12987 and consider consolidating these reports if you're experiencing the same error across different MCP servers.

@github-actions[bot] commented on GitHub (Feb 11, 2026): This issue appears to be a duplicate of #12987, which reports the identical TypeError with MCP tool calls. Both issues involve the same root cause: OpenCode's client-side MCP response parser expecting a nested `output.output` structure when the MCP servers are correctly returning a flat `output` structure. Please check #12987 and consider consolidating these reports if you're experiencing the same error across different MCP servers.
Author
Owner

@roshitx commented on GitHub (Feb 11, 2026):

🎯 Root Cause Found!

The bug is NOT in OpenCode core - it's in Oh-My-OpenCode (OMO) plugin v3.5.0.

Evidence

User on Windows 11 confirmed:

rollback to oh-my-opencode@3.4.0 fixed this issue for me

Release: https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v3.5.0

Fix

For users with OMO plugin:

# Rollback to v3.4.0
npm install -g oh-my-opencode@3.4.0
# or
bun install -g oh-my-opencode@3.4.0

For users without OMO:
The bug is OMO-specific. If you're not using Oh-My-OpenCode plugin, this issue doesn't apply.

Action Items

  1. Bug is in OMO v3.5.0, not OpenCode core
  2. Should report to: https://github.com/code-yeongyu/oh-my-opencode/issues
  3. Workaround: Rollback to OMO v3.4.0

Closing this issue as it's not an OpenCode bug. Will report to OMO repo.

@roshitx commented on GitHub (Feb 11, 2026): ## 🎯 Root Cause Found! The bug is NOT in OpenCode core - it's in **Oh-My-OpenCode (OMO) plugin v3.5.0**. ### Evidence User on Windows 11 confirmed: > ``` > rollback to oh-my-opencode@3.4.0 fixed this issue for me > ``` **Release:** https://github.com/code-yeongyu/oh-my-opencode/releases/tag/v3.5.0 ### Fix **For users with OMO plugin:** ```bash # Rollback to v3.4.0 npm install -g oh-my-opencode@3.4.0 # or bun install -g oh-my-opencode@3.4.0 ``` **For users without OMO:** The bug is OMO-specific. If you're not using Oh-My-OpenCode plugin, this issue doesn't apply. ### Action Items 1. ✅ Bug is in OMO v3.5.0, not OpenCode core 2. ⏳ Should report to: https://github.com/code-yeongyu/oh-my-opencode/issues 3. ✅ Workaround: Rollback to OMO v3.4.0 Closing this issue as it's not an OpenCode bug. Will report to OMO repo.
Author
Owner

@roshitx commented on GitHub (Feb 11, 2026):

Closing - Bug is in Oh-My-OpenCode plugin v3.5.0, not OpenCode core. Will report to https://github.com/code-yeongyu/oh-my-opencode

@roshitx commented on GitHub (Feb 11, 2026): Closing - Bug is in Oh-My-OpenCode plugin v3.5.0, not OpenCode core. Will report to https://github.com/code-yeongyu/oh-my-opencode
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#9050