[FEATURE]: Support MCP Resources (resources/read) in addition to MCP Tools #15535

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

What to add

OpenCode currently connects to MCP servers and exposes their tools (tools/call) to the AI, but does not implement the resources capability (resources/list, resources/read) defined in the MCP specification.

MCP servers can expose both tools and resources. Resources are identified by URIs and represent readable content — files, documents, or structured data that the AI can fetch on demand. Without resources/read support, the AI cannot access any of these, even when the MCP server explicitly serves them.

Concrete example

An MCP server exposes documentation as resources under a custom URI scheme. Each skill tool returns a summary, but the full reference material (e.g. API references, templates, scripts) lives in sub-resources like:

skill://my-skill/references/some-reference.md

In Cursor (which implements resources/read), the AI can fetch this URI directly through the MCP server. In OpenCode, it cannot — the only fallback is reading the file from the local filesystem, which breaks in remote or containerized environments where the files aren't mounted.

What to change

1. During MCP server initialization, negotiate the resources capability alongside tools.
2. Expose a mechanism for the AI to call resources/read with a URI, and return the resource contents (text or blob).
3. Optionally: expose resources/list so the AI can discover available resources without needing to know URIs in advance.

Benefits

• Full MCP spec compliance — resources are a first-class capability in MCP 2025-11-25; supporting them makes OpenCode a complete MCP client.
• Richer context for AI — MCP servers often serve supplementary reference material (docs, templates, examples) via resources that tools alone cannot surface.
• Environment-agnostic access — resource content comes from the MCP server itself, so it works in remote/containerized setups where the local filesystem isn't available.
• Parity with other MCP clients — Cursor already supports this; the gap makes OpenCode a second-class citizen when working with resource-heavy MCP servers.