OpenCode's MCP support follows the same JSON-config model as most agent CLIs, but its provider-agnostic design means the way tool calls surface in the terminal can differ depending on which model backend you've pointed it at. Google Drive MCP works fine here — the friction, when there is any, tends to show up around long tool-call chains and less-forgiving models rather than the Drive integration itself.
Installing and Connecting Google Drive MCP to OpenCode
OpenCode reads MCP server definitions from opencode.json (project-level) or ~/.config/opencode/opencode.json (global). Both stdio and remote (HTTP) transports are supported, matching the two realistic Drive MCP options: a locally-run stdio server holding your OAuth credentials, or a hosted server like Zapier's.
For a local stdio setup:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"gdrive": {
"type": "local",
"command": ["npx", "-y", "@modelcontextprotocol/server-gdrive"],
"environment": {
"GDRIVE_CREDENTIALS_PATH": "/Users/you/.config/gdrive-mcp/.gdrive-server-credentials.json",
"GDRIVE_OAUTH_PATH": "/Users/you/.config/gdrive-mcp/gcp-oauth.keys.json"
},
"enabled": true
}
}
}
If you're routing through a hosted MCP endpoint instead (e.g. a Zapier-managed Drive connector), the config switches to a remote transport:
{
"mcp": {
"gdrive": {
"type": "remote",
"url": "https://mcp.zapier.com/api/mcp/s/YOUR_SERVER_ID/mcp",
"enabled": true
}
}
}
Just as with Claude Code, run the local server's own auth flow before pointing OpenCode at it — OpenCode has no interactive OAuth-callback handling of its own, so if the credentials file doesn't already exist, the server will fail to start rather than prompt you through a browser flow mid-session.
npx @modelcontextprotocol/server-gdrive auth
npx @modelcontextprotocol/server-gdrive auth
Verify the connection from inside an OpenCode session:
opencode
/mcp
This lists registered servers and their connection state. A server stuck in a connecting or errored state almost always traces back to one of two things: the command array pointing at a binary that isn't actually on PATH inside the environment OpenCode spawns (worth testing the exact array manually in your shell first), or the credentials path being wrong. Run the command array manually before assuming OpenCode's config parsing is at fault:
GDRIVE_CREDENTIALS_PATH=/Users/you/.config/gdrive-mcp/.gdrive-server-credentials.json \
GDRIVE_OAUTH_PATH=/Users/you/.config/gdrive-mcp/gcp-oauth.keys.json \
npx -y @modelcontextprotocol/server-gdrive
If that runs cleanly and logs a "server ready" style message to stderr, the OpenCode config is fine and the issue is elsewhere (permissions on the config file, a typo in the JSON, or OpenCode not picking up the project-level config because it's not in the working directory OpenCode was launched from).
Tips
- Test the exactcommandarray fromopencode.jsondirectly in your shell before debugging inside OpenCode — it isolates config-parsing issues from actual server startup issues.
- Put project-shared Drive server config in the project-levelopencode.jsononly if the credentials path is safe to reference relatively across every machine on the team; otherwise keep it in the global config and just share the folder-ID conventions in project docs.
- Run/mcpat the start of any session that depends on Drive access — catching a disconnected server before you start prompting saves a round of confused "why isn't it finding anything" troubleshooting.
Listing, Searching, and Reading Drive Files from OpenCode
Once connected, the workflow inside OpenCode mirrors any other agent CLI: describe intent, let the model pick tools. OpenCode's TUI shows each tool call inline as it happens, which is genuinely useful for Drive work specifically — you can watch the actual q query string the model constructed and catch a bad search before it wastes a turn.
Search Drive for Google Docs containing "SLA" in the /Legal folder,
list titles and last modified dates, don't open anything yet.
Watching the tool call appear lets you verify the model correctly scoped the query with a folder filter rather than searching the entire Drive — a mistake that's easy for a model to make if the folder ID wasn't given explicitly and it instead tried (and likely failed) to filter by folder name in the q string, which Drive's API doesn't support directly. Folder name filtering has to go through a separate lookup first: search for the folder by name and MIME type, get its ID, then use that ID in a parents filter.
name = 'Legal' and mimeType = 'application/vnd.google-apps.folder'
If you're prompting the agent to do this multi-step lookup itself, say so explicitly rather than assuming it will chain the calls correctly on the first attempt:
First, find the Drive folder ID for the folder named "Legal" by
searching for mimeType = folder and name = 'Legal'. Then use that
folder ID to list files inside it. Show me the folder ID you found
before listing its contents.
Reading a file once located is a single tool call, and OpenCode surfaces the raw returned content in the transcript, which is worth glancing at at least once per new document type you work with — it's the fastest way to notice export degradation (a table that came back as a wall of unaligned text, for instance) before it silently corrupts a downstream summary.
Tips
- Watch the actual search query OpenCode's tool call panel shows before trusting the results — a folder-name filter that Drive's API silently ignores is a common, invisible failure mode.
- When targeting a folder by name, explicitly instruct a two-step lookup (find folder ID, then filter by it) rather than assuming the model will chain calls correctly without guidance.
- Spot-check raw exported content in the transcript the first time you work with a new document type — catching export degradation early is cheaper than debugging a wrong summary later.
Practical Example: Building a Requirements Summary from a Folder of Docs
A concrete end-to-end run: a folder called /Product/Mobile Onboarding has six Docs accumulated over two months of iteration, and you need one requirements summary before starting implementation.
1. Find the Drive folder ID for "/Product/Mobile Onboarding" (search by
name and folder mimeType, confirm the parent path if there are
multiple folders with similar names).
2. List every Google Doc inside that folder, sorted by modifiedTime
descending.
3. Read the three most recently modified documents in full.
4. Produce a single consolidated requirements list. For any requirement
that appears differently across the three documents, flag it under
a "Needs Clarification" heading instead of picking one version
silently.
5. Cite which document each requirement came from.
Running this as one structured prompt rather than five separate ones keeps OpenCode's tool-call sequence coherent — the model plans the full chain up front instead of you manually re-prompting after each step, and the explicit "don't pick one silently" instruction is what prevents a confident but arbitrary merge.
A realistic output shape looks like this once it comes back:
## Onboarding Requirements Summary
### Confirmed Requirements
- Users can skip onboarding after step 2 (source: "Mobile Onboarding
Flow v3", modified 2026-07-30)
- Progress indicator shows step count, not percentage (source: "Design
Review Notes - Onboarding", modified 2026-08-02)
### Needs Clarification
- Skip behavior: "v3" doc says skip returns to step 1 on next login;
"Design Review Notes" implies skip is permanent for that session.
These conflict — confirm with product before implementing.
That "Needs Clarification" section is the actual deliverable value here — it's the list a human reviewer should read first, because it's the difference between a spec you can safely implement against and one that will produce a mid-sprint surprise.
For folders with more than roughly ten documents, don't try to read everything in one pass — first list and skim titles/dates to pick the genuinely relevant subset, then run the deep-read step only on those. Reading every historical draft indiscriminately both burns context and increases the odds of the summary weighting a stale draft as heavily as the current version.
Tips
- Structure folder-to-summary work as one multi-step prompt so OpenCode plans the full tool-call chain coherently, rather than re-prompting manually after each step.
- Always request a "Needs Clarification" or equivalent section for conflicting requirements — it's frequently the most valuable part of the output, not an afterthought.
- Pre-filter by title and date before deep-reading a large folder; reading everything indiscriminately dilutes the summary with stale drafts.
Known Limitations for Google Drive MCP in OpenCode
A few things worth knowing before you rely on this combination for anything time-sensitive.
No native OAuth callback handling. OpenCode itself doesn't manage the browser-based consent flow — it only spawns the MCP server process and talks to it over the configured transport. If a token expires and the underlying server doesn't refresh it silently (a real gap in some community server implementations), you'll see a generic tool-call failure in OpenCode with no browser prompt to fix it. You have to drop out to a terminal, re-run the server's standalone auth command, and restart the OpenCode session.
Model-dependent tool-call reliability. Because OpenCode supports swapping model providers, the quality of multi-step Drive tool chaining (folder-ID lookup → list → read → summarize) varies more than it would in a single-provider tool. Stronger models handle the implicit "look up the ID first" reasoning without being told explicitly; weaker or smaller models sometimes skip straight to a name-based parents filter that Drive's API silently returns zero results for, and OpenCode won't flag that as an error — it'll just report an empty result set as if the folder were genuinely empty.
No built-in caching of search results across turns. Each search re-hits the Drive API, which is fine for occasional use but means repeatedly refining a search query re-executes the full request rather than filtering a cached result client-side. For iterative search-narrowing sessions, this is a minor latency cost, not a functional problem — but it does mean rate limits (Drive's default quota is generous, but shared service accounts on a busy team can bump into per-user-per-100-seconds limits) are a real, if uncommon, consideration during heavy exploratory search sessions.
Export fidelity issues are identical to other clients since they originate in the MCP server's export call, not in OpenCode — this isn't an OpenCode-specific limitation, but it's worth repeating here because it's easy to blame the wrong layer when a table comes back scrambled.
npx @modelcontextprotocol/server-gdrive auth
Tips
- If a Drive tool call fails mid-session with no clear error, assume an expired/unrefreshed token first — re-run the server's auth command in a separate terminal rather than debugging OpenCode's config.
- Use a stronger model for tasks requiring multi-step folder-ID lookups; weaker models silently return empty results from name-based folder filters instead of erroring, which is easy to misread as "the folder is empty."
- Don't blame OpenCode for export fidelity problems — table and formatting degradation comes from the underlying MCP server's export call and is identical across every client using that same server.
Tips
Tips
- Verify the server command works standalone in your shell before trusting OpenCode's/mcpstatus — it separates config problems from actual server problems immediately.
- Structure folder-wide summarization as a single multi-step prompt with explicit conflict-flagging instructions rather than a loose back-and-forth — it produces a more reliable, reviewable output.
- Keep the model backend in mind when relying on multi-step tool chaining — Drive workflows that need a folder-name-to-ID lookup are exactly the kind of implicit reasoning weaker models skip.