OpenCode 1.17.6 Fixes an MCP Honesty Bug: Do Not Advertise What You Cannot Do
OpenCode 1.17.6 fixes the kind of bug that should make every MCP client maintainer slightly uncomfortable: the client now says what it can actually do. Not what it might support later. Not what the surrounding ecosystem expects. What it can handle today.
That sounds small because capability declarations are small. It is not small. In an agent runtime, the tool catalog is a contract between the MCP server, the client, the model, and the human who will be surprised when the workflow takes a path nobody implemented. If the client advertises support for roots, sampling, elicitation, tasks, or other MCP features it cannot execute, the server may reasonably initiate flows the client cannot complete. Best case, the user sees a confusing failure. Worse case, the model plans around a capability that never truly existed.
OpenCode v1.17.6, published June 13 with 37 release assets, is compact: five commits and 32 changed files from v1.17.5. The headline bugfix is “Improved MCP server compatibility by declaring OpenCode’s supported client capabilities.” The more useful sentence appears in PR #32222: unsupported capabilities are deliberately kept commented out “so OpenCode does not advertise behavior it cannot handle.” That is the right instinct for agent infrastructure. Honesty beats optimistic interoperability.
MCP capability negotiation is not decorative metadata
MCP has become the default answer to “how does my coding agent reach everything else?” GitHub, Slack, databases, docs, issue trackers, internal APIs, browser automation, design tools, cloud control planes: the pitch is that a server exposes tools and the agent can use them. OpenCode’s own docs support local and remote MCP servers. Local config includes command, cwd, environment, enabled, and timeout. Remote config includes URL, headers, OAuth, enabled, and timeout. The docs also warn that MCP tools add to context and can “quickly add up,” with GitHub MCP called out as token-heavy enough to exceed context limits.
That warning matters because MCP is not just a plug-in format. It is a distributed boundary with auth, schema, latency, capability, and context-pressure failure modes. Capability negotiation is one of those boundaries. If the client declares support for behavior it does not implement, the server does not know it should avoid that branch. If OAuth completion creates a slightly different client option set than the initial connection, you get a bug that appears only after the user signs in. If the model sees a tool landscape built on false claims, its plan can be coherent in text and impossible in execution.
PR #32222 centralizes client options across the normal connection path and OAuth completion path. It makes the MCP client capabilities object explicit and documents unsupported sampling, elicitation, roots, and tasks capabilities with tracking issues. That centralization is not just cleanup. Auth flows are where agent tools often fork into alternate code paths. A client that behaves one way before OAuth and another way after OAuth is exactly how a team burns an afternoon debugging a server that “works locally” but fails in the real integration.
For practitioners, the lesson is direct: test what your agent says it supports, not just whether one MCP call succeeds. Configure a remote MCP server with OAuth. Configure a local server with cwd. Connect a token-heavy server like GitHub and watch context pressure. Inspect declared client capabilities if your server exposes advanced MCP flows. Then test the unhappy paths. The agent that wins is not necessarily the one with the largest tool catalog. It is the one whose tool catalog tells the truth.
The project-move fixes are the same maturity story
The rest of 1.17.6 cleans up project move and copy failure paths. PR #32226 catches project directory refresh and listing failures in the move dialog, surfaces the API error in a toast, and returns an empty directory result so Solid does not propagate a rejected resource into a global fatal error boundary. PR #32234 ignores project copy strategies that cannot use a persisted source directory during refresh and adds regression coverage for a persisted directory whose Git metadata has been removed.
This is not as protocol-flavored as MCP capability hygiene, but it points at the same product stage. Coding agents are no longer stateless chat boxes that happen to edit files. They maintain project roots, sessions, snapshots, copy strategies, UI state, provider credentials, tool catalogs, and sometimes background loops. Users move repos. They delete .git directories. They operate inside generated worktrees, temporary clones, mounted volumes, dev containers, and CI workspaces. A terminal UI should not crash because a directory refresh fails or a persisted source root no longer looks like the code assumed it would.
Graceful degradation is part of agent safety. If a TUI falls into a fatal boundary during a project move, the user loses trust in the whole harness. If it reports the error and keeps the session alive, the failure stays local. The same principle applies to MCP: if unsupported capabilities are not advertised, the failure never gets invited into the workflow in the first place.
This release also gives OpenCode a useful position in the broader coding-agent comparison. Claude Code still has a strong polish advantage and deep user mindshare. Codex is building migration paths, app/browser surfaces, plugin routing, and a more explicit control plane. Qwen Code is moving toward daemon, desktop, workflow, team, and cron runtime features. OpenCode’s wedge remains open-source inspectability, multi-provider flexibility, and a willingness to expose the harness as software you can reason about. That wedge only works if the operational edges are boring enough to trust.
Open-source agents do not need to cosplay completeness
The temptation in protocol ecosystems is to overclaim. Every project wants the compatibility badge. Every integration wants to appear as capable as the most ambitious server. But agent clients are different from passive libraries. Their claims shape what the model tries, what servers send, and what humans approve. A false capability is not just a documentation bug; it can become a runtime path with missing user interaction, missing policy enforcement, or missing state handling.
OpenCode’s choice to comment out unsupported features is therefore more than prudence. It is a design posture. Support the MCP features you can honor. Leave the rest visible in code as future work. Do not let the marketing surface outrun the runtime. That is how open-source agent infrastructure earns trust: not by pretending to match every proprietary tool feature-for-feature, but by making its contracts inspectable.
Teams evaluating OpenCode should use 1.17.6 as a nudge to audit their own assumptions. Pin the version. Read the MCP config. Confirm local cwd behavior. Validate remote OAuth. Check logs. Try provider-specific tool schemas. Remove Git metadata from a copied project and watch the UI. If that sounds tedious, welcome to agent operations. The work is not glamorous, but neither is debugging a model plan built on a capability the client never had.
The release is small, but the editorial takeaway is large: coding agents should not advertise what they cannot do. The ecosystem will be healthier if more clients take that sentence literally.
Sources: OpenCode release, OpenCode MCP docs, PR #32222, PR #32226, PR #32234, v1.17.5...v1.17.6 compare