Qwen Code’s MCP Resource Support Turns Servers Into Usable Context
MCP started as tool plumbing. Qwen Code’s PR #5544 points at the more interesting future: MCP as a context plane. The difference matters. Tools let an agent do things. Resources let a user choose what the agent knows before it acts. If local coding agents are going to move beyond “read my repo and pray,” they need that middle layer between manual copy-paste and opaque memory systems. Qwen Code’s new MCP resource support is a practical step in exactly that direction.
The PR merged on June 21 at 2026-06-21T11:04:52Z and is included in the v0.18.5 release published later the same day. It was not a trivial autocomplete patch: GitHub shows 12 commits, 2,423 additions, 207 deletions, 40 files changed, 11 issue comments, and 110 review comments. That review volume is a tell. MCP resource support touches discovery, registries, session views, prompt handling, message injection, binary attachment behavior, compatibility rules, tests, and the user’s mental model of what context entered the conversation.
The user-facing flow is simple. Qwen Code now discovers MCP resources with resources/list, tracks them through a new ResourceRegistry, shows prompt and resource counts in /mcp, autocompletes resource URIs after @server:, and lets a user submit prompts such as summarize @server:<uri>. Text resources are injected inline. Binary resources are handled as attachments. A visible “Read MCP Resource” tool card makes the read explicit instead of silently mixing server data into the model context.
Resources are the missing middle of agent memory
The official MCP resources specification describes resources as application-driven context identified by URI: files, database schemas, logs, generated indexes, runbooks, documentation, or app-specific records. The spec deliberately leaves UI patterns to hosts. A client might show a tree, a search box, filters, or explicit user selection. Qwen Code’s terminal-native answer is @server:uri. It is not fancy. It is legible. That is a feature.
There is a large and mostly unhelpful industry habit of calling every persistent context feature “agent memory.” A vector database stuffed with embeddings is one kind of memory. A hand-maintained rules file is another. A workspace index is another. An MCP resource is different: it is structured, server-owned context that can be selected at the moment it is needed. That is often the cleaner abstraction for engineering work. A database schema should not necessarily live forever in the chat. A deployment runbook should not be invisibly blended into every turn. A generated API map should not be pasted by hand each time someone asks for a refactor. It should be addressable, discoverable, and explicitly pulled into the session.
That explicitness is what makes Qwen Code’s implementation worth covering. The old local-agent checklist was model quality, repository indexing, shell tool, edit tool, and maybe cost controls. The new checklist includes host quality: can the agent discover external context reliably? Can users see which server exposed it? Can they autocomplete the URI? Can the host separate text resources from binary resources? Does it make the read visible in the transcript? Does it avoid confusing local file mentions such as @path/to/file with remote MCP resource mentions such as @server:uri? PR #5544 adds tests for that distinction, which is exactly the kind of small UI/protocol boundary that prevents debugging misery later.
Lenient clients, imperfect servers
The compatibility decision in #5544 is more interesting than the feature list. Qwen Code no longer relies strictly on a server’s declared prompts or resources capabilities before attempting discovery. Instead, it tries prompts/list and resources/list, then treats Method not found as the real boundary. The PR notes the reason: some MCP servers implement the list methods but under-declare their capabilities during initialization, making prompts invisible in stricter clients while more lenient clients surface them.
Protocol purists will dislike this, and they have a point. The MCP spec says servers that support resources must declare the resources capability. Capability negotiation exists for a reason. A client that papers over broken servers can make the ecosystem sloppier because bad implementations still appear to work. But the opposite failure mode is also real: a useful server works in one MCP host and appears empty in another because one field in initialization is wrong. For builders trying to wire local agents into actual workflows, that is not a philosophical debate. It is a support ticket.
Qwen Code’s compromise is defensible: attempt the list calls and swallow Method not found. That keeps genuinely unsupported servers quiet while allowing under-declared-but-working servers to function. Server authors should not read this as permission to ignore the spec. They should read it as evidence that client authors are being forced to design around ecosystem messiness. If your MCP server depends on lenient clients to be usable, you have shipped a bug with a lucky compatibility layer.
The same dynamic applies to prompts. The MCP prompts specification describes prompts as user-controlled templates typically exposed through UI affordances such as slash commands. Qwen Code already had prompts-as-commands; #5544 makes discovery more forgiving. That matters because prompts and resources together are the start of a real agent workspace: reusable task templates plus selectable external context.
Context is an input channel, so govern it like one
The security angle is not that MCP resources are bad. The security angle is that MCP resources are inputs, and inputs shape agent behavior. A resource can contain stale documentation, malicious instructions, secrets, irrelevant binary data, or a carefully phrased prompt-injection payload embedded in a runbook. If a team treats @server:uri as harmless because it “only adds context,” it has already lost the plot. Context is not passive. In agent systems, context is an instruction-adjacent control surface.
Qwen Code’s visible read card helps because it gives the user and transcript a record of what was pulled in. That is much better than silent automatic context stuffing. But organizations still need policy. Which MCP servers are trusted? Which resource namespaces can be read without approval? Are resource reads logged? Can a server expose resources from outside the expected project? Are binary resources scanned or clearly separated from text? Do internal resources include prompt-injection warnings or provenance metadata? What happens when a resource changes between two runs? These are not enterprise-theater questions. They are the difference between a useful local-agent stack and a confusing, un-auditable context blender.
There is also a product-scale caveat. Resource support can become resource clutter. A serious MCP server may expose hundreds or thousands of URIs: database tables, service docs, tickets, logs, package metadata, generated indexes, source artifacts, design docs. Autocomplete works only if naming, descriptions, filtering, pagination, and server organization are sane. Qwen Code now has the foundation. The next challenge is making resource selection scale without turning the prompt box into a warehouse inventory system.
For practitioners, the immediate move is to design MCP resources deliberately instead of dumping everything behind a server and calling it memory. Good resources should have stable URIs, human-readable names, accurate descriptions, clear ownership, and predictable freshness. Put database schemas, API contracts, runbooks, and generated project maps behind MCP resources. Avoid exposing broad, poorly labeled buckets that encourage users to inject half the company wiki into a coding turn. Prefer explicit user selection for sensitive or high-impact context. Treat resource reads as auditable events.
The broader take: MCP is becoming less about giving agents more buttons and more about giving humans better control over what agents see. Qwen Code #5544 is pragmatic in the right places: lenient where the server ecosystem is messy, explicit where context enters the model, and terminal-native enough that developers will actually use it. Resources are the missing middle between paste-driven workflows and magical memory. Qwen Code just made that middle layer feel real.
Sources: GitHub PR: QwenLM/qwen-code #5544, Qwen Code v0.18.5 release, MCP Resources specification, MCP Prompts specification, MCP Transports specification.