Copilot was falling back to text search instead of using the MCP-backed graph context

[Harshad-994]

Copilot was falling back to text search instead of using the MCP-backed graph context

Summary

I ran into an issue where GitHub Copilot was not behaving like I expected in a large project. Instead of consistently using the MCP-backed knowledge graph / structured context, it seemed to fall back to plain text search and direct file scanning.

After I changed the instruction file, the behaviour improved and Copilot started using the graph context much more effectively.

What I expected

I expected Copilot to:

• use the MCP server / graph context first
• reason over the project structure instead of repeatedly grepping files
• stay efficient across repeated related questions

What actually happened

Before the instruction change, Copilot appeared to rely mostly on text search and raw file exploration. In a repeated Q&A session on the same codebase, context usage climbed quickly and the session compacted earlier than expected.

Observed behaviour before the fix

• after repeated questions, context reached nearly 50%
• the session compacted
• after more questions, usage was around 53% overall

Observed behaviour after the fix

Once I updated the instruction file, Copilot behaved much better in the same style of workflow.

• after 10 same questions, context stayed around 28%
• the session remained lighter
• Copilot was able to reuse the graph-oriented context instead of repeatedly re-reading the repo

What I changed

The main change was updating the instruction file so Copilot had clearer guidance to use the graph / MCP-backed workflow rather than defaulting to text search.

That change made a visible difference in how the assistant handled the same project questions.

Questions I’m asking

1. Is there a supported way to make Copilot prefer MCP-backed context more reliably?
2. Is text search still expected as a fallback even when an MCP server is available?
3. Are there recommended instruction patterns to keep Copilot on the structured graph path?

Proof / screenshots

After Graphify-assisted workflow

Non-graphify workflow

Why this matters

For large, interconnected projects, repeated text search becomes expensive and harder to trust. A structured graph workflow keeps the session more stable and makes it easier to answer follow-up questions about related features, flows, and dependencies.

My takeaway

The instruction file change made the biggest difference. Without it, Copilot seemed to stay too close to text search. With it, the assistant started acting much more like a graph-aware coding partner. And use this MCP server for project only as different projects have different graphs.

If anyone has tips for making this more reliable, I’d love to hear them.

--

Here is the same copilot-instruction file I used to resolve this occurring issue :

MANDATORY: Use Knowledge Graph Before Anything Else

This project has a pre-built knowledge graph at graphify-out/graph.json.

RULES (follow strictly):

1. For ANY question about how code works, use query_graph MCP tool FIRST
2. For ANY question about how two things connect, use get_neighbors or shortest_path FIRST
3. Do NOT open or search raw files until graph query returns no result
4. Do NOT use grep, file search, or read files to answer architecture questions
5. The graph already contains extracted concepts, relationships, and rationale from all files

How to Use the Graph

• Understanding a feature → query_graph("feature name")
• How A connects to B → shortest_path("A", "B")
• What uses X → get_neighbors("X")
• Specific node details → get_node("node id")

Only Fall Back to Files When

• Graph returns empty result
• Question is about exact line numbers or syntax
• You need to edit specific code

---

thanks for this @safishamsi

[safishamsi]

Great write-up and thanks for sharing your instruction file — this is exactly the kind of real-world feedback that helps improve the default skill.

To answer your questions directly:

1. Is there a supported way to make Copilot prefer MCP-backed context more reliably? Yes — the instruction file approach you used is the right one. The graphify copilot install command writes a .github/copilot-instructions.md section that includes graph-first rules. If you ran that, the section may not have been strong enough; the custom version you shared is more directive and that's fine.

2. Is text search still expected as a fallback? Yes, it's Copilot's default. The instruction file can't fully disable it, but strong mandatory language ("Do NOT open or search raw files until graph query returns no result") reliably shifts the behavior as you observed.

3. Are there recommended instruction patterns? Your version is good. The key elements are: explicit priority order, specific MCP tool names, and a clear fallback condition. One addition that helps: Always read GRAPH_REPORT.md first to understand community structure before querying.

Your context numbers (28% vs 53%) are a great concrete data point — pinning this for anyone else hitting the same issue.