Hi, certainly our MCP server can get the files you want it to for example, and issues and things, so you likely can do what you need with it, but it depends a bit on whether you want to the agent to be able to do.

One exception is you cannot use our MCP to pull down URLs for research outside of GitHub content, so you would likely need a tool for web fetch too.

Depending on your constraints, I expect GitHub MCP could enable a lot of what you want, but for stuff that is provided up-front/deterministic you might want to just fetch that stuff ahead of time for the agent via code.

@WestonG40 Absolutely

What MCP can do for your use case

MCP is very good at the GitHub‑related parts of your workflow:

• Expose a GitHub repository or selected files to the model (via the GitHub MCP server)

• Control exactly what the model can access (you decide which tools are available)

• Provide deterministic, auditable inputs (the model only sees what your MCP tools expose)

This covers your step:

1. “Assign a few files or a repository to the chat.”

What MCP cannot do by itself

From the GitHub maintainer’s reply:

“You cannot use our MCP to pull down URLs for research outside of GitHub content.”

This means:

• MCP cannot fetch arbitrary websites

• MCP cannot enforce “only use these 3 URLs” unless you build that logic yourself

• MCP cannot return citations automatically — you must implement that behavior in your tools or UI

So your step:

2. “In the prompt I mention 3 websites to be also considered.”

…requires your own custom tool, not just MCP.

What a complete solution looks like

To replicate the Copilot Web UI behavior, you would build:

1. Your own MCP server

This server would expose:

• A GitHub tool (via GitHub’s MCP server or your wrapper)

• A Web‑fetch tool (your own code that fetches only the 3 allowed URLs)

• A Source‑tracking tool (optional: returns metadata about what was used)

2. A custom UI

Your UI would:

• Let the user “attach” files or repos

• Let the user specify the 3 allowed websites

• Send these as structured inputs to the model

• Display the model’s answer + the sources your tools report

3. A policy layer

This enforces:

• “Only use these files and these URLs”

• “Do not access anything else”

• “Return citations for every piece of information”

This is not something the model enforces automatically — you enforce it by controlling the tools.

How the workflow would look in practice

Step A — User selects files + URLs

Your UI sends something like:

{
  "allowed_files": ["repo/path/a.md", "repo/path/b.md"],
  "allowed_urls": ["https://site1.com", "https://site2.com", "https://site3.com"]
}

Step B — Your MCP tools fetch only those

• GitHub tool → returns file contents

• Web tool → fetches only the allowed URLs

• Both return metadata for citation tracking

Step C — Model receives a structured context package

Not raw internet access — only what you explicitly provide.

Step D — Model answers and includes citations

Because your tools return structured metadata, the model can cite them.

When MCP is the right choice

MCP is ideal if you want:

• Strict control over what the model can access

• Deterministic inputs (files, URLs, structured data)

• A custom UI that behaves like Copilot Web but tailored to your workflow

• A secure boundary (model cannot “escape” and browse the internet)

This matches your scenario very well.

When MCP is not enough by itself

If you expect:

• Automatic web browsing

• Automatic citation extraction

• Automatic “only use these sources” enforcement

…then MCP alone won’t do it. But MCP + your own small tools absolutely can.

A simple architecture recommendation

This is the closest equivalent to the Copilot Web UI — but fully under your control.