How to ensure OpenCode uses MCP extensively? #950

A pattern that works well is to make CGC visible as a deliberate planning and code-navigation tool instead of expecting the model to discover it on every turn.

Checklist I would try:

1. Confirm the MCP server is actually visible to OpenCode. Run cgc mcp start separately once and check that the configured command/args match the OpenCode MCP config. If OpenCode has a tool list or debug logs, verify the CGC tools show up there before testing prompts.

2. Index the repo first, then ask questions that clearly require graph context. For example: Use CodeGraphContext to inspect this repo first. Find the call chain for X and identify files that would be affected if I change it. Generic prompts like fix this bug often let the model stay inside normal file reads.

3. Add a persistent instruction for the project: Before making architectural changes, dependency changes, or cross-file refactors, query CodeGraphContext for callers, callees, imports, and affected modules. This makes tool use part of the agent policy instead of a one-off prompt.

4. Start with narrow CGC queries. Ask for one symbol, one module, or one relationship type first. Once the model sees useful results, follow with broader impact-analysis prompts.

5. If it still avoids MCP, test with an explicit forced prompt: Do not answer from local files yet. First call the CGC MCP tools to locate the relevant symbols and relationships, then summarize what you found.

In practice, MCP use depends a lot on prompt pressure and whether the model thinks the graph will reduce uncertainty. For OpenCode specifically, I would first verify tool registration, then add a project instruction that requires CGC before refactors or multi-file reasoning.