mcp-google-multi

Overview Schema Source Related Servers Discussions Admin

google_api_call

Destructive

Invoke any Google Workspace REST method by Discovery id (escape hatch for operations without a dedicated tool). Find methods with google_api_search first.

Instructions

Invoke any Google Workspace REST method by Discovery id (escape hatch for operations without a dedicated tool). Find methods with google_api_search first. A write asks the connected human to confirm the real call (account, verb, params, a destinations-first body summary) unless GOOGLE_PROFILE=full-writes with no outbound allowlist; GOOGLE_READ_ONLY or a matching GOOGLE_WRITE_DENY still refuse outright. On reads, pass a fields query param (Google partial response) to keep the payload small. Returns JSON only; for binary/file content (media downloads, drive.files.export) use drive_download / drive_export instead.

Input Schema

Name	Required	Description
`api`	Yes	API alias: gmail, drive, calendar, sheets, docs, slides, forms, people, searchconsole, tasks, chat, meet, driveactivity, drivelabels, admin_directory, admin_reports, admin_datatransfer, groupssettings, analyticsadmin, analyticsdata, appsmarket, classroom, cloudidentity, cloudsearch, groupsmigration, keep, licensing, postmaster, reseller, script, vault, workspaceevents
`body`	No	JSON request body
`account`	No	Google account alias (omit for the default account)
`methodId`	Yes	Discovery method id, e.g. "drive.revisions.list"
`pathParams`	No	Values for {placeholders} in the method path
`queryParams`	No	Query-string parameters; use an array for repeated params (e.g. resourceNames)

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv5.4.1Sep 30, 2026

changedInput schema / properties / account / description

Previous value: -"Google account alias"New value: +"Google account alias (omit for the default account)"

changedInput schema / properties / api / description

Previous value: -"API alias: gmail, drive, calendar, sheets, docs, slides, forms, people, searchconsole, tasks, chat, meet, driveactivity, drivelabels, admin_directory, admin_reports, admin_datatransfer, groupssettings, appsmarket, classroom, cloudidentity, cloudsearch, groupsmigration, keep, licensing, postmaster, reseller, script, vault, workspaceevents"New value: +"API alias: gmail, drive, calendar, sheets, docs, slides, forms, people, searchconsole, tasks, chat, meet, driveactivity, drivelabels, admin_directory, admin_reports, admin_datatransfer, groupssettings, analyticsadmin, analyticsdata, appsmarket, classroom, cloudidentity, cloudsearch, groupsmigration, keep, licensing, postmaster, reseller, script, vault, workspaceevents"

addedInput schema / properties / api / maxLength
```
Added value: +64
```
addedInput schema / properties / methodId / maxLength
```
Added value: +256
```
addedInput schema / properties / methodId / minLength
```
Added value: +1
```

removedInput schema / properties / pathParams / additionalProperties / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]

addedInput schema / properties / pathParams / additionalProperties / type
```
Added value: +[
+  "string",
+  "number"
+]
```

changedInput schema / properties / queryParams / additionalProperties / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "items": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "number"
-        },
-        {
-          "type": "boolean"
-        }
-      ]
-    },
-    "type": "array"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "items": {
+      "type": [
+        "string",
+        "number",
+        "boolean"
+      ]
+    },
+    "type": "array"
+  }
+]

changedInput schema / required

Previous value: -[
-  "account",
-  "api",
-  "methodId"
-]New value: +[
+  "api",
+  "methodId"
+]

First observedv0.0.0-semantically-releasedAug 11, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations, which only say destructive/non-idempotent/open-world: the description discloses the human-confirmation flow for writes (account, verb, params, destinations-first body summary) and the exact env-var gates (GOOGLE_PROFILE=full-writes with no allowlist, GOOGLE_READ_ONLY, GOOGLE_WRITE_DENY) that refuse calls. It also declares JSON-only output. This is consistent with destructiveHint=true and readOnlyHint=false, not contradictory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with what it is, then discovery routing, then write/read behavior, then the binary exclusion. Every sentence carries information an agent needs to call it correctly; no restatement of the name or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, nested-object, open-world tool with no output schema, the description still covers discovery of methodIds, write-confirmation behavior, read payload sizing, return format, and where to go for binary content. An agent has enough to call it safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description earns above that by documenting the `fields` query param trick for partial responses and implying queryParams is where read-side options go. It does not explain body vs pathParams vs queryParams beyond the schema, keeping it at 4 rather than 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Invoke any Google Workspace REST method by Discovery id') and immediately frames its role as an 'escape hatch for operations without a dedicated tool', which cleanly separates it from the many *_discover siblings. An agent knows exactly what class of operation belongs here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit sequencing ('Find methods with google_api_search first'), an explicit when-not rule (prefer dedicated tools), and a concrete exclusion with alternatives ('for binary/file content ... use drive_download / drive_export instead'). Nothing about selection is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

google_api_call

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools