Because the official servers sit on the Google Cloud side, the project owner, not the individual user, decides who connects and what it costs. In a shared setup, one named project holds billing and each user's access is granted inside it. A personal sandbox project belongs to one person and shouldn't be reused for the team. ### AI client plans required for Google MCP connectors Whether a built-in connector works depends on the plan you hold with the AI client, not on anything Google sells. Prices differ widely: [Claude's pricing page](https://claude.com/pricing) lists a $0 free tier with limited usage, and [OpenAI's](https://openai.com/chatgpt/pricing) lists $8 and $20 monthly tiers. Check the connector's own listing against your tier before you buy, because a plan that lacks it makes the upgrade the real cost. ## Connecting Google account to MCP client setup Work through four stages and a Google account is talking to an MCP client. The stages are a Cloud project with the Drive API enabled, an OAuth consent screen and credentials, the server added to the client config, and a read-only test. Each one leaves something working, so you can stop and check before moving on. ### Stage 1: Create a Google Cloud project and enable the API Create the project under the account that will own it, because the project, not the person, is what Google bills and audits. A project made on a personal login stays with that login when the person leaves.  A team should therefore create it under a shared or organization account. In the Google Cloud console, create a new project and give it a name that says what it is for. Then open the API library, search for Google Drive API, and enable it. You now have a project that accepts Drive requests. Nothing can call it yet. Next comes the OAuth consent screen and credentials. The consent screen is what you see when the client asks to read your files, so fill it in as the person who will be approving it. 1. Set the app to external unless your organization uses Workspace and the app is for internal use only. 2. Add the read-only Drive scope and nothing broader. Write access can't be granted by accident if it was never requested. 3. While the app is in testing, add your own address as a test user. Without that, the sign-in is refused. 4. Create an OAuth client of the desktop application type and download its JSON file. Keep that file out of any shared repository. It holds the client secret. ### Stage 3: Add the MCP server to the client config Pick a Google Drive MCP server and follow its own README, because the exact config keys differ between servers. Most clients take a JSON entry with a command to launch, its arguments, and a pointer to the credentials file from Stage 2. Restart the client afterward. The first launch should open a browser window for Google's sign-in, and the server should appear in the client's tool list once you approve it. ### Testing Google MCP read-only and checking granted scopes Ask the client to list the files in one Drive folder. If names come back, the chain works from end to end. Then check what you actually granted. Google's account permissions page lists the app and its access. It should show read-only Drive access and nothing more. Be aware that the read-only scope covers your whole Drive, not one folder, so the folder limit comes from how you phrase the request or from the server's own settings. Test it by asking for a folder you didn't name and seeing what the server does. ## Common Google MCP mistakes and a Monday checklist Even when an over-permissive server fails the unnamed-folder test, five mistakes sit upstream of it, and each one costs you a different amount of time or exposure: - Assuming a Google One plan includes API or MCP access - Requesting broad write scopes - Leaving an OAuth app in Testing mode and letting tokens expire - Hitting a Workspace admin block - Installing an unverified community server Three of these are covered below, and the checklist at the end puts them in order. Nothing in a larger Google One tier buys API quota or an MCP endpoint, because it is a consumer storage subscription. Paying for a bigger tier buys storage and consumer features. Any connection still runs through a Google Cloud project and OAuth consent, so the plan you pay for doesn't change what a server can do. ### Google MCP OAuth scope and test-mode token mistakes The broader the permission your app asks for, the longer Google takes to approve it, and that permission is called a scope.  Google's [OAuth verification documentation](https://support.google.com/cloud/answer/13463817?hl=en) puts brand verification at 3 business days, which is a logo and app name check you can absorb in a week. 10 business days is the wait for sensitive scopes, so a request for Calendar write access delays launch by two working weeks. **Restricted scopes take 30 business days**, which means a request for full Drive access can eat a whole quarter's sprint before one user connects. Ask for the narrowest scope that does the job. While waiting, an app in Testing mode keeps working, but its tokens expire quickly. A server that worked on Friday can fail on a later Friday with no code change, so treat sudden auth errors as a mode problem first. ### Personal versus Workspace accounts blocking Google MCP On a work account, administrators can block third-party apps outright, because Workspace is Google's managed business suite. A server that connects to your personal account may be refused on your work account, and you can't fix that from your side. Ask the admin to allow the app's client ID before you debug anything else. The same rule applies to community servers: if nobody has verified the code, an admin is right to block it, and you should read the source before you grant it a token. Monday checklist: 1. Decide which of the three real things you want: a consumer plan, an API connection, or an MCP server. 2. Write down the narrowest scope that does the job. 3. Check that scope's verification tier and its 3, 10 or 30 business days against your deadline. 4. Move the app out of Testing mode, or schedule token renewals. 5. Ask your Workspace admin about the app before the first sign-in. 6. Read the source of any community server, then run the unnamed-folder test. ## Connecting Google apps to an AI assistant with Activepieces Unlike an unverified community server, Activepieces has an MIT-licensed core, so you can read what it does. It can expose Google Drive, Gmail and Calendar to an AI client as one MCP server.  It's an automation platform, and it has nothing to do with a Google One subscription. Take one thing from the diagram below: **the client talks to one endpoint you control**, not to three separate Google connections, and MCP access is included on the free plan at $0, which means you can start building without budget friction. Three Google apps feed one Activepieces flow, which exposes a single MCP server that the AI client connects to. !(diagram) ### When a workflow tool beats a direct server Choose Activepieces when the job crosses apps. It has 750 integrations, and MoneyGram, Moneypenny, Alan and FundingSocieties run it, while a direct server from Google covers Google's own product, meaning you're backing battle-tested infrastructure. When you want an assistant to read a Calendar invite, find the matching file in Drive and draft a Gmail reply, a flow can do those steps in a fixed order. The assistant calls it as one tool. That means fewer chances for the model to improvise a bad sequence. It also settles who is responsible. Activepieces holds each Google connection, one of its 750 integrations, under whichever account signs in to it, so that account's data is what the assistant can reach. If that's a personal login, everything the flow touches is that person's mailbox. If the connection lives in a shared team project, someone on the platform side owns the connection and decides which flows may use it. Decide that before you build, not after.  You now run, or pay for, another system, and that is the cost. A direct server has one fewer thing to maintain. Do it in this order, because the Google authorization comes before anything the assistant can see. 1. Create an Activepieces project and decide which account owns it. 2. Add a connection for each Google app, granting only the access the flow needs. A flow that reads Calendar shouldn't hold Gmail send rights. 3. Build the flow from the Drive, Gmail and Calendar integrations (Activepieces' name for its prebuilt app integrations). 4. Expose the flow through the platform's MCP server feature, which gives you an address and a credential for the client. 5. Paste that address into your AI client, then test with a harmless read-only request first. Treat the credential from step 4 like the token the previous section warned about: it lets whoever holds it act through your connections. Check the current steps against Activepieces' own documentation, since menu names change. ## Frequently asked questions Is there an official Google One MCP server? No. Google One is a consumer storage and subscription plan, and I know of no Google page that describes an MCP server under that name. Google's MCP offerings are tied to specific services, so confirm any claim against Google's own developer documentation. ### Does my Google One or Google AI plan include MCP access? No. A subscription pays for storage and Google's consumer AI features, not for a protocol endpoint. When a Google-run MCP server is available, billing follows the underlying service. A cloud project pays for cloud usage, so the invoice lands where the project's billing account sits, not on your personal plan. Assume the underlying API's limits apply, since Google hasn't published separate MCP quota figures, and check that API's quota page. ### Can Claude or ChatGPT read my Google Drive through MCP? Yes, but the route depends on the product. Inside each app, you switch on its own Drive connector and authorize it with your Google account. That's a vendor-built integration, not something you host. If you want a custom MCP server in front of Drive, you build or install one, and then you own the authorization setup. For personal use, an app requesting sensitive Drive scopes may display an unverified-app warning until it passes Google's verification review. Verification matters when other people use your app, not when you test it yourself on your own account. ### Is a community Google MCP server safe to use? It's as safe as the code and the permissions you grant it, which is a decision you make, not Google. Read the source, check who maintains it and how recently, and grant the narrowest scope that does the job. A read-only Drive scope limits the damage if something goes wrong. Grant a full-access scope and a stranger's code gets your whole file history. Run it under a Google account you can afford to lose until you trust it. If a team will use it, the platform owner should approve it first, because a personal experiment that touches shared documents becomes a departmental risk. Does Gemini support MCP servers? Yes, in some Google products. Google's developer tooling, including its command-line agent and its SDKs, documents MCP support. The consumer Gemini app is a different surface, and its connector options are set by Google, not by you. Check the specific product's documentation before you build around it. ## Related reading - [Google Docs API Rate Limits for Developers (2026)](https://www.activepieces.com/blog/google-docs-api-rate-limits-for-developers-2026) - [Snowflake Pricing Explained for 2026 Data Teams](https://www.activepieces.com/blog/snowflake-pricing-explained-for-2026-data-teams) - [GitHub Copilot Fusion Explained for AI Coding Teams](https://www.activepieces.com/blog/what-is-github-copilot-fusion-ai-model-routing) ## References - [MCP Top List](https://mcptoplist.com/observatory) - [Google Cloud Help](https://support.google.com/cloud/answer/13463817?hl=en) - [Google One](https://one.google.com/about/)Paying for more storage doesn't buy a connector.