Feature request: expose existing Drive download/export capability through a bounded MCP tool

Open
  • Is something wrong?
#1,275 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
api, devtools

Research direction

Read internal/cmd/mcp_tools.go around drive_search and drive_get, then inspect internal/cmd/drive_download.go and the existing MCP export work in #1181. Define the tool interface, artifact receipt, output ownership, byte limits, and cleanup contract before implementation. Done means Drive download/export is available through MCP with a bounded local artifact contract.

Written by the indexing model from the issue text.

Description

clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster P3

gog drive download already retrieves files such as PDFs and exports Google-native documents. For clients that can invoke the CLI, that is sufficient.

For Agents already using gog's MCP integration, a content-acquisition tool would let them continue from Drive search and metadata to a downloaded file using the server's configured account and structured arguments, rather than switching to a separate shell invocation. The motivation is a simpler, consistent operation and file handoff, with less command construction—not a missing CLI capability.

A narrow tool could reduce opportunities for invocation mistakes, but we have not measured Agent success rates for CLI versus MCP. The concrete gap established below is only that the existing MCP Drive tools expose search and metadata, not download/export.

At 82e7fd6005d4ed29f8edfa2a44475e08fe3051a0:

Credential-free source check

From a gogcli checkout containing that revision, run:

python3 - <<'PY'
import re
import subprocess
revision = '82e7fd6005d4ed29f8edfa2a44475e08fe3051a0'
def source(path):
    return subprocess.check_output(['git', 'show', f'{revision}:{path}'], text=True)
mcp = source('internal/cmd/mcp_tools.go')
cli = source('internal/cmd/drive_download.go')
names = sorted(set(re.findall(r'Name:\s*"(drive_[^"]+)"', mcp)))
print('Revision:', revision)
print('MCP Drive tools:', ', '.join(names))
print('CLI DriveDownloadCmd exists:', 'type DriveDownloadCmd struct' in cli)
print('MCP download/export input:', any('download' in n or 'export' in n for n in names))
PY

Observed:

Revision: 82e7fd6005d4ed29f8edfa2a44475e08fe3051a0
MCP Drive tools: drive_get, drive_search
CLI DriveDownloadCmd exists: True
MCP download/export input: False

This confirms the source/interface gap. It does not exercise a Google download; no credentials, Google API calls or live accounts were used for this check.

Would exposing this existing capability as a bounded MCP tool fit the project's direction? A PDF download would cover the immediate use case; optional exports could reuse the existing CLI formats if useful. A small file-ID/format input and a structured artifact receipt could make this easier for Agents already using the MCP tools. We have a downstream implementation and would follow your preferred interface, including any artifact/handle conventions appropriate alongside the bounded MCP export work in #1181.

By read-only, I mean no mutation of Drive. Downloading still creates local data, so output ownership, byte limits and cleanup need an explicit contract rather than exposing an arbitrary output path. The appropriate return format and storage lifetime are design questions, not requirements to adopt our downstream choices.

Source diagnosis and credential-free source reproduction: gpt-6.1-sol. Drafting: gpt-6.1-sol. No live-download verification or independent review was performed for this proposal.

Dominant language
Go
Stars
8.5k
Forks
721
Avg merge
19h 47m
Merged PRs (30d)
53

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/gogcli

All issues in openclaw/gogcli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.