Gmail, Drive, Docs, Sheets in Sume: why they are coming soon
Gmail, Drive, Docs and Sheets stay coming soon in Sume until Google Developer Preview enrollment and the read allowlists are verified.
You cannot connect Gmail, Google Drive, Docs or Sheets to a Sume workspace today. Sume has the connector design, but Google documents these MCP services as Developer Preview, and the connectors stay coming soon until the enrollment and the live reads are verified. In that state, Connect and demos are disabled, saved connections do not appear usable, and agents do not list or call the tools.
What exists in the code
The workspace integrations doc describes confidential PKCE OAuth clients for all four, each with its own environment keys and a callback under /api/integrations/{provider}/callback. The requested scopes are read-only: gmail.readonly, drive.readonly, documents.readonly and spreadsheets.readonly. The design has no dynamic registration path for them.
What the allowlists would allow
| Connector | Reads in the design |
|---|---|
| Gmail | Message, thread, draft, label and thread-search reads |
| Google Drive | File search, recent files, metadata, permissions and content reads |
| Google Docs | read_doc |
| Google Sheets | get_spreadsheet, get_values |
What is deliberately left out
The allowlists do not include label mutation, message send, file create, update_doc, update_values or other write tools. Even once enabled, these connectors would only read.
The gate
Google says the project and the account must enroll in the Workspace Developer Preview Program. The doc is blunt that a successful OAuth and tool discovery alone do not prove that reads are usable. Until someone verifies enrollment and live reads, the four stay coming soon on the dev and production destinations. The code shares this gate through integrationAvailability, and the dashboard hides these rows entirely.
What to do today
If you need a file or an email in an agent run now, hand the content in yourself: upload the media to Sume, or pass a public media URL where an endpoint accepts one. For the 25 MB mail attachment problem with video, see Gmail's attachment limit and the Drive link fallback. Check the Integrations page for the current rows rather than assuming a connector exists.
How you will know it changed
A provider moves out of coming soon when the availability gate flips for it. The visible sign is a row on the Integrations page with a working Connect button, and the agent tools appearing in a new turn. Until you see the row, assume it is off, whatever the code in the repo prepares.
Also remember the order of verification the doc asks for: enrollment first, live reads second. A successful consent screen is not proof.
Sources
Related posts
More in Integrations
- WordPress media_handle_sideload for a Sume music mp3 attachment
Download the Sume artifact URL with download_url(), then media_handle_sideload() it into the Media Library. It returns an attachment id or a WP_Error.
- Connected-app tools in Sume: plugin prefixes and the mcp:read rule
Tools from a connected app get a provider namespace such as slack_plugin_ or meta_plugin_, need mcp:read, and a plugin outage does not break unrelated tools.
- X media upload APPEND: 5 MB chunks, and how to split a Sume MP4
The X API v2 APPEND step takes chunks of at most 5 MB. Count the segments for a Sume MP4 with a short script before you upload to the initialize endpoint.
- X media upload processing_info states: poll until succeeded
After FINALIZE on the X API v2, processing_info moves from pending to in_progress to succeeded or failed. Poll using check_after_secs, then post the Sume video.
Written by Sume