MCP Resources Not Accessible to AI Agents - Breaking Intended Use Cases

[cboettig]

VS Code's MCP implementation exposes resources only through the UI ("Browse Resources" command) but not programmatically to AI agents. This breaks legitimate use cases where resources contain metadata, schemas, or catalogs that agents need to reference during tool invocation.

Current Behavior

What happens now:

1. MCP server exposes resources via resources/list and resources/read methods (per MCP spec)
2. VS Code successfully calls these methods and displays resources in the "Browse Resources" UI
3. However, AI agents (GitHub Copilot) have NO programmatic access to:
   • List available resources (resources/list)
   • Read resource contents (resources/read)
4. Resources are only accessible if a user manually:
   • Opens "Browse Resources" (F1 → type "Browse")
   • Manually attaches the resource to chat context

Evidence from codebase:

• McpServerRequestHandler.listResources() exists but is only called from UI code
• McpServerRequestHandler.readResource() exists but is only called from UI code
• No agent-accessible tools like mcp_<server>_list_resources are generated
• Resources remain in UI domain only (see McpResourceQuickAccess, McpBrowseResourcesCommand)

Expected Behavior

According to the Model Context Protocol specification, resources are designed to expose:

"Resources represent any kind of data that an MCP server wants to make available to clients. This can include:

• File contents
• Database schemas
• API responses
• Live system data
• Screenshots and images
• Log files
• And more"

The spec clearly envisions programmatic access, not just UI browsing.

What should happen:

1. MCP server exposes resources
2. VS Code makes them available to AI agents via callable tools OR automatic context injection
3. Agent can programmatically discover and read resources during task execution

Real-World Use Case (Blocking Issue)

I maintain duckdb-geo, an MCP server providing access to geospatial datasets. It exposes:

Resource: catalog://list
Content: Markdown documentation listing 10 available datasets with:
  - S3 paths (s3://public-wetlands/glwd/hex/**)
  - Schema information (columns: Z, h8, h0)
  - Query optimization hints
  - Usage examples

Problem: When a user asks "What datasets are available?", the AI agent:

• ❌ Cannot call resources/list to discover the catalog
• ❌ Cannot call resources/read to read catalog://list
• ✅ CAN only access this info if I embed it in the tool description (bloating every tool call)

Current workaround: Duplicate ~2KB of catalog documentation into the query tool's description, which:

• Increases token usage on every tool invocation
• Makes tool descriptions harder to read
• Requires server restart to update
• Doesn't scale (if catalog grows, tool description becomes unwieldy)

Why this matters:

• Database schema servers need to expose table definitions
• API servers need to expose endpoint documentation
• File servers need to expose directory listings
• Data catalogs need to expose available datasets

Proposed Solution

Add agent-accessible resource operations similar to how tools are exposed. Options:

Option 1: Auto-generate resource tools (Recommended)

For each connected MCP server with resources capability, expose:

mcp_<server-id>_list_resources()  // Returns array of available resources
mcp_<server-id>_read_resource(uri: string)  // Returns resource content

This mirrors how MCP prompts could be exposed programmatically.

Option 2: Server instructions enhancement

Allow servers to specify in their initialize response:

{
  "instructions": "Available datasets can be listed via the catalog://list resource",
  "autoLoadResources": ["catalog://list"]  // Auto-inject these as context
}

Option 3: Agent directive

Add configuration allowing agents to automatically read specific resource patterns:

{
  "chat.mcp.autoLoadResources": true,
  "chat.mcp.resourcePatterns": ["catalog://**", "schema://**"]
}

Impact

Affected users:

• MCP server developers using resources for metadata/schemas
• Users with servers that expose catalogs, documentation, or dynamic data
• Anyone building data-oriented MCP servers (databases, APIs, file systems)

Current impact:

• Forces duplication of resource content into tool descriptions (inefficient)
• OR requires manual user intervention (breaks automation)
• Discourages use of resources feature
• Creates confusion about intended resource use cases

References

MCP Specification:

• Resources: https://spec.modelcontextprotocol.io/specification/2025-11-05/server/resources/
• Tools: https://spec.modelcontextprotocol.io/specification/2025-11-05/server/tools/

VS Code Implementation:

• McpServerRequestHandler: src/vs/workbench/contrib/mcp/common/mcpServerRequestHandler.ts (lines 519-543)
• McpResourceQuickAccess: src/vs/workbench/contrib/mcp/browser/mcpResourceQuickAccess.ts
• McpBrowseResourcesCommand: src/vs/workbench/contrib/mcp/browser/mcpCommands.ts (lines 1045-1064)

Related Components:

• Tools ARE exposed to agents via generated callable functions
• Prompts could potentially be exposed similarly
• Resources are the missing piece

Additional Context

Why not just use tools?
Resources are semantically different from tools:

• Tools = actions/operations the agent can invoke
• Resources = data/content the agent can reference
• Resources can be large, static, or frequently referenced
• Resources support subscriptions for live updates

Having a dedicated resource mechanism (per MCP spec) is cleaner than forcing everything into tool results.

Comparison with other clients:
Other MCP clients (like Claude Desktop) may handle this differently. VS Code should provide first-class resource access to maintain feature parity with the MCP specification.

Questions for Maintainers

1. Was the UI-only approach for resources intentional, or is this incomplete implementation?
2. Would you accept a PR that adds agent-accessible resource tools?
3. Are there concerns about token usage if agents can freely read resources?
4. Should this be opt-in behavior (security/privacy)?

Environment

• VS Code Version: 1.97+ (MCP support introduced)
• Extension: GitHub Copilot (all versions with MCP support)
• MCP Server: duckdb-geo (https://github.com/boettiger-lab/duckdb-mcp), but affects all MCP servers using resources
• OS: Linux/Windows/macOS (affects all platforms)

---

Labels suggestion: feature-request, mcp, copilot, chat
Priority: Medium-High (blocks legitimate use cases, forces workarounds)

[connor4312]

related: #251747

[CHR-LeeOlsen]

This would help me as well. I have a custom prompt that tells copilot to attempt to fetch an api spec for a downstream dependency from our backstage MCP server. If the spec exists, use it to plan the desired changes. If the MCP server for this resource has not been setup then provide a link to our blog post. If the resource doesn't return that API spec (it's not in our catalog) then provide a link to another blog post describing how to get their API spec into the catalog and ask the user to provide the detail manually for now.

I understand not allowing tools during plan mode. I also understand someone could abuse an mcp resource to mutate state but I'd put that on them.

I'm going to attempt to work around this by having the custom prompt instruct it to do this during implementation and put the branching logic of behavior into the plan so that it'll do that behavior during implementation phase.