Fix fetch tool to only handle HTTP/HTTPS schemes for MCP resources

[Copilot]

The fetch web page tool was incorrectly attempting to process MCP resource URIs (like test://static/resource/50), which would fail because these non-HTTP schemes cannot be loaded in Electron's BrowserWindow.

Problem

When users tried to fetch MCP resource content, the fetch tool would:

1. Accept any URI scheme in FetchWebPageTool._parseUris()
2. Pass it to NativeWebContentExtractorService.extract()
3. Attempt to load the URI in an Electron BrowserWindow via win.loadURL()
4. Fail because BrowserWindow only supports HTTP/HTTPS protocols

This resulted in the error shown in the issue where the tool couldn't retrieve MCP resource content.

Solution

Modified FetchWebPageTool._parseUris() to only accept HTTP and HTTPS schemes:

// Only accept http and https schemes for web content extraction
if (uriObj.scheme === 'http' || uriObj.scheme === 'https') {
    results.set(uri, uriObj);
} else {
    results.set(uri, undefined);
}

Changes

• Modified FetchWebPageTool._parseUris() to filter out non-HTTP(S) schemes
• Added comprehensive tests for scheme filtering behavior in fetchPageTool.test.ts

User Experience

• Before: Attempting to fetch test://static/resource/50 would cause errors or unexpected behavior
• After: Non-HTTP URLs are treated as "invalid" with clear user feedback: "the following was an invalid URL: test://static/resource/50"
• HTTP/HTTPS URLs: Continue to work exactly as before
• MCP resources: Can still be accessed through VS Code's filesystem providers as intended

Benefits

• ✅ Resolves the MCP resource fetch failure shown in the issue screenshot
• ✅ Follows @TylerLeonhardt's suggestion that fetch tool should only handle HTTP/HTTPS
• ✅ Aligns with @connor4312's insight about VS Code filesystem serving MCP resources
• ✅ Provides clear user feedback for unsupported URL schemes
• ✅ No breaking changes for existing HTTP/HTTPS functionality
• ✅ Minimal, surgical code change

Fixes #250495.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• electronjs.org
  • Triggering command: node-gyp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[TylerLeonhardt]

I'd rather the tests implemented a TestWebContentExtractorService which can be constructed with a map of like "Uris to fake page contents" and then have tests that test the actual API not private methods

[Copilot]

I'd rather the tests implemented a TestWebContentExtractorService which can be constructed with a map of like "Uris to fake page contents" and then have tests that test the actual API not private meth...

I've refactored the tests to use a TestWebContentExtractorService that implements IWebContentExtractorService with configurable URI-to-content mapping. The tests now validate the public API behavior (via the invoke method) instead of testing private methods directly. This approach provides better test isolation and follows testing best practices. Commit: a62dae1

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• electronjs.org
  • Triggering command: node-gyp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

[connor4312]

I think what would be nice here is actually to just serve the file data if it's something the IFileService can resolve. Sure it might not be 'correct' use of the fetch tool, but that would make usages of it not break :)

[Copilot]

I think what would be nice here is actually to just serve the file data if it's something the IFileService can resolve. Sure it might not be 'correct' use of the fetch tool, but that would make usages...

I've implemented your suggestion to serve file data via IFileService for non-HTTP/HTTPS schemes. The fetch tool now:

1. Processes HTTP/HTTPS URLs through the web content extractor (unchanged)
2. Processes other URLs through IFileService.readFile()
3. Only marks URLs as "Invalid" if both approaches fail

This makes MCP resources work seamlessly - instead of rejecting test://static/resource/50, it now attempts to read the content via the file service. The tool gracefully falls back to "Invalid URL" only if the file service can't handle the scheme either.

Commit: 2df3c81

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• electronjs.org
  • Triggering command: node-gyp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

[TylerLeonhardt]

I like the strategy of:

• if we get an HTTP or HTTPS url, use the web extractor
• otherwise try the IFileService to resolve the url return content if it does
• otherwise mark them as invalid

However, let's not change the description of the tool as I don't want this fall back to be used too heavily over other read tools.

And remember order matters in what you return back so maintain the same order in the response.

[Copilot]

I like the strategy of:

• if we get an HTTP or HTTPS url, use the web extractor
• otherwise try the IFileService to resolve the url return content if it does
  ...

I've reverted the tool description back to the original text that only mentions web pages, while keeping the file service fallback functionality intact. The tool maintains proper URL order in responses as requested. Commit: 9c36f75

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• electronjs.org
  • Triggering command: node-gyp (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

[TylerLeonhardt]

Can you use this FileService implementation as the implementation on the web? Right now that's using the Null one

[Copilot]

Can you use this FileService implementation as the implementation on the web? Right now that's using the Null one

I've implemented a FileService-based WebContentExtractorService for the web platform. The web workbench now uses FileServiceWebContentExtractorService instead of NullWebContentExtractorService, which allows HTTP/HTTPS URLs to be handled via the FileService infrastructure. Commit: 1d2d406