Cline lists resources and prompts into a UI tab and has no way to fetch either

Kind: idiosyncrasy · Status: current · Last verified: 2026-08-25 · Clients: cline · Revisions: 2025-11-25

McpHub.fetchServerCapabilities runs four list calls on every connect: tools/list, resources/list, resources/templates/list and prompts/list. Each is gated on the server having declared the capability, each treats a MethodNotFound as an authoritatively empty list rather than a failure, and each result is cached on the connection.

Three of those four go nowhere. resources/read does not appear in the repository. Neither does prompts/get, readResource, getPrompt, ReadResourceResult or GetPromptResult. The lists reach exactly one consumer: two tabs in the server configuration panel, which render a count and then the URIs, names and descriptions as text.

What the model gets is tools alone. createVscodeExtraTools passes McpHub's server list to the shared createMcpTools, which reads provider.listTools(serverName) and returns one flat agent tool per MCP tool. Nothing else on the connection is offered to it.

access_mcp_resource is a dead enum entry

The tool id survives:

export enum ClineDefaultTool {
	…
	MCP_USE = "use_mcp_tool",
	MCP_ACCESS = "access_mcp_resource",
	…
}

MCP_ACCESS has no registration, no handler and no executor. The only other reference is a webview branch that would render the tool call if one ever arrived. Cline's own history is the explanation — access_mcp_resource was a real tool before the agent loop moved onto @cline/core — but at this commit the model cannot emit it and nothing would run it if it did.

Why it matters for the matrix

A boolean matrix would give Cline resources: yes, and the apify entry does exactly that. So would reading the wire: Cline calls resources/list, so it looks like a client that consumes resources. A server author choosing between exposing data as a resource and exposing it as a read_* tool would make the wrong call on either signal.

This is also the sharpest case yet of the gap [[utilized-capability-declarations]] describes. Cline consumes nothing it lists, and there is no field in the handshake that could say so — the client capability object it sends is empty, and resources was never a client capability to declare in the first place.

Codex and opencode both solved the same problem by exposing three built-in tools that read resources on the model's behalf, described in [[model-initiated-resource-read]]. Cline lists the same data and stops.

Sources