The GAM MCP Server provides 13 administrative tools for managing Google Workspace via service account impersonation (Domain-Wide Delegation), covering users, groups, Gmail, Drive, and Sheets.
User & Group Management
Create user accounts with optional auto-generated passwords
Move users between Organizational Units or re-parent OU hierarchies
Sync Google Group memberships by computing and applying membership diffs
List users, groups, and group members with pagination (JSON or CSV output)
Gmail Compliance & Auditing
Search any user's mailbox using Gmail query syntax (returns metadata + snippets)
Fetch full details of a specific email, including recursively decoded MIME body parts
Bulk delete emails matching a query (defaults to dry-run with sample previews)
Drive Security Auditing
List Drive file metadata across user, domain, or Shared Drives
Stream permissions audits to local files (CSV or JSONL) in a memory-safe manner
Sheets Integration
Export local CSV audit files to Google Sheets in 2000-row chunks
Read worksheet ranges to feed data into administrative automation workflows
Safety Features: All mutating tools default to dry-run mode; a read-only mode blocks all writes; output paths are allowlisted and symlink-rejected.
Provides tools for searching, fetching, and bulk deleting emails within a Google Workspace domain, with features like MIME decoding, pagination, and dry-run support for bulk operations.
Offers file listing and permission auditing across user, domain, or shared drives, with memory-safe streaming to disk for large audits.
Enables exporting audit data from CSV to Google Sheets in safe chunks, and reading sheet ranges for administrative automation, with CSV injection defense.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GAM MCP Server create a new user for John Doe"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A high-performance, secure, memory-safe Model Context Protocol (MCP) server that implements Google Workspace administrative controls (Directory, Gmail, Drive, Sheets) via Domain-Wide Delegation (DWD) service account impersonation.
Designed as a modern TypeScript alternative to traditional GAM scripts, this server provides a structured, schema-validated toolset that integrates with any Model Context Protocol host (such as Antigravity or Claude Desktop).
Resilient Rate-Limiting: API requests are wrapped in exponential backoff with fractional randomized jitter. The retry classifier distinguishes retryable (429, 5xx, 403/quotaExceeded, network ECONNRESET/ETIMEDOUT/etc.) from non-retryable errors (400, 403/forbidden, 403/insufficientPermissions), and honors Retry-After headers when the server provides one.
Stream-to-Disk Operations: StreamDiskWriter pipes large search and audit responses line-by-line directly to local files at 0600 permissions, bypassing standard V8 heap limits to prevent Node.js Out-Of-Memory (OOM) crashes.
Concurrency-Limitation Gates: A strict write-concurrency queue limited to maximum 5 active operations for Directory mutations, and 10 concurrent Drive audit list pages.
Token-Scrubbing Filter: Globally intercepts stdout and stderr to mask access tokens (ya29.*), refresh tokens (1//0*), ID tokens (eyJ*.*.*), and PEM private key blocks before any bytes are flushed. Idempotent.
POSIX Security Guard: Validates service account key file permissions on startup, emitting a high-visibility security warning if the key is world- or group-accessible. Called exactly once at startup.
Path Allowlist: All tool I/O paths (audit outputs, CSV imports) are resolved under GAM_MCP_OUTPUT_DIR (or cwd if unset). Paths that escape the root are rejected, as are any paths whose ancestry contains a symlink.
CSV Injection Defense: Spreadsheet-bound output prefixes leading =, +, -, @, \t, \r with a single quote per OWASP guidance, preventing formula injection when audits are opened in Excel or Sheets.
JWT Client Cache: DWD JWT instances are cached per (subject, scopes) so the underlying google-auth-library access-token cache is reused across many calls within a single audit.
Multi-line CSV Reader: The Sheets exporter correctly joins records that span multiple physical lines (RFC 4180 §2.6).
Structured Logging: A stderr-only logger emits human-readable text in test mode and single-line JSON in prod mode (set via NODE_ENV or GAM_MCP_ENV). Log level is gated via --log-level / GAM_MCP_LOG_LEVEL.
Related MCP server: google-cloud-mcp
gam_admin_create_user: Creates user accounts. password is optional — if omitted, a cryptographically secure 32-character base64url password (~192 bits of entropy) is generated and returned ONCE in the response.
gam_admin_update_ou: Moves a user or re-parents an OU. Requires explicit targetType: 'user' | 'ou' (no auto-detection from @).
gam_admin_sync_group_members: Computes membership diffs and syncs concurrently up to the 5-concurrency write limit. If a group's membership exceeds the MAX_PAGES_LIMIT read cap, the diff would be computed against partial membership: a dry-run returns truncated: true with a warning, and a real sync is refused to avoid a destructive partial sync.
gam_admin_print_users: Paginated user listing (up to MAX_PAGES_LIMIT pages) in CSV or JSON.
gam_admin_print_groups: Paginated group listing in CSV or JSON.
gam_admin_print_group_members: Paginated active-member listing in CSV or JSON.
gam_gmail_search_messages: Searches a mailbox and returns metadata + snippets of the first N results in CSV or JSON.
gam_gmail_get_message: Fetches details for a single email, decoding base64url MIME parts recursively (depth-capped at 20).
gam_gmail_bulk_delete: Batch deletes emails matching a query in chunks of 1000 IDs (Gmail's API limit). Default dry-run shows up to 15 sample previews. When more messages match than can be enumerated within the MAX_PAGES_LIMIT page cap, the response sets truncated: true and the message instructs you to re-run (or narrow the query) to delete the remainder.
gam_drive_list_files: Lists file metadata. Accepts corpora: 'user' | 'domain' | 'drive' | 'allDrives' to widen the search scope (use allDrives for Shared Drives).
gam_drive_audit_permissions: Memory-safe permission audit. Streams flattened rows to a file under GAM_MCP_OUTPUT_DIR with the inherited-ancestry cache active across the run. Also accepts corpora.
gam_export_audit_to_sheets: Streams a local CSV (which MUST live under GAM_MCP_OUTPUT_DIR) to a Sheet tab in safe 2000-row chunks. Auto-creates missing tabs.
gam_read_admin_sheet: Reads a worksheet range to feed targeting data back into administrative automation runs.
Note: Gmail, Drive, and Sheets tools no longer accept adminUserEmail — the DWD impersonation subject is always the named mailbox/Drive/Sheet owner (userEmail).
To authorize this service account, a Google Workspace Super-Admin must configure Domain-Wide Delegation (DWD) inside the Google Workspace Admin Console.
Go to the Google Cloud Console.
Create or select a project (e.g., gam-mcp).
Enable the following APIs:
Admin SDK API (admin.googleapis.com)
Gmail API (gmail.googleapis.com)
Google Drive API (drive.googleapis.com)
Google Sheets API (sheets.googleapis.com)
Navigate to IAM & Admin > Service Accounts and create a Service Account (e.g., gam-mcp-sa).
Generate and download a JSON credentials key. Save it securely.
Set secure POSIX file permissions:
chmod 0600 ~/secrets/oauth2service.jsonNote the Client ID (Unique ID) of the service account.
Log into the Google Workspace Admin Console as a Super Admin.
Go to Security > Access and data control > API controls.
Under Domain-wide delegation, click Manage Domain Wide Delegation.
Click Add new, enter the Client ID, and paste these OAuth scopes:
https://www.googleapis.com/auth/admin.directory.user,
https://www.googleapis.com/auth/admin.directory.group,
https://www.googleapis.com/auth/admin.directory.group.member,
https://www.googleapis.com/auth/admin.directory.orgunit,
https://www.googleapis.com/auth/drive.readonly,
https://www.googleapis.com/auth/gmail.readonly,
https://mail.google.com/,
https://www.googleapis.com/auth/spreadsheets,
https://www.googleapis.com/auth/spreadsheets.readonly(https://mail.google.com/ is only required for gam_gmail_bulk_delete.)
Save the delegation.
Requires Node.js 20+ LTS (enforced via package.json engines).
cd gam-mcp
npm install
npm run build
npm run test # unit + integrationThe server resolves settings in this precedence order (highest wins):
CLI flags (see below)
Environment variables
Config file (--config <path>)
Built-in defaults
gam-mcp-server [options] [credentials.json]
OPTIONS:
-c, --credentials <path> Service-account JSON key file.
--config <path> Path to a key=value (or key: value) config file.
--log-level <level> error | warn | info | debug
--read-only Block all mutating tool invocations.
--dry-run Treat mutating tools as dry-runs by default.
-h, --help Show help and exit.
-v, --version Show version and exit.Variable | Purpose |
| Path to the service-account JSON key. |
| Same, but standard GCP env var. |
| Path to a config file (same format as |
|
|
|
|
| Allowlist root for tool I/O. Defaults to cwd. |
|
|
A template is provided in .env.example.
Lines are key = value or key: value. # and ; introduce comments.
credentials = /Users/me/secrets/oauth2service.json
log_level = info
read_only = false
output_dir = /Users/me/gam-mcp-audits~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"gam-mcp": {
"command": "node",
"args": [
"/Users/yourname/src/gam-mcp/build/index.js",
"--log-level", "info"
],
"env": {
"GAM_MCP_CREDENTIALS": "/Users/yourname/secrets/oauth2service.json",
"GAM_MCP_OUTPUT_DIR": "/Users/yourname/gam-mcp-audits"
}
}
}
}Register the server inside your Antigravity MCP registry, ensuring the absolute path to build/index.js is correct.
Read-Only Command Gate: When enabled (via --read-only or GAM_MCP_READ_ONLY), all mutating operations are blocked at the executor level. Dry-runs still proceed.
Fail-Safe Dry-Runs: All mutating tools default to dryRun: true. Bulk delete additionally surfaces 15 sample previews on dry-run.
Stderr-Only Logging: The MCP stdio transport requires a pristine stdout. The logger writes ONLY to stderr; stdout is reserved for JSON-RPC.
Token Scrubbing: Every byte written to stdout/stderr is scanned for known token patterns and masked.
Output Path Allowlist: Audit writes and CSV imports cannot escape GAM_MCP_OUTPUT_DIR. Symlink-bearing paths are rejected. Files are created with mode 0600.
Closed-By-Default Error Policy: Errors are returned to MCP callers as text content with isError: true; full stack traces (including cause chains) go to stderr at debug/warn levels.
File | Purpose |
| Original developer specification (historical roadmap). |
| This file (operational reference). |
| Live status tracker. |
| Architectural design notes. |
| Verification log per release. |
| Environment template. |
MIT.
Creates a new user account in the Google Workspace directory. If password is omitted on a non-dry-run, a secure random password is generated and returned ONCE in the response.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | Validate without creating the user (default true). | |
| password | No | Optional explicit password (>=8 chars). If omitted, one is generated. | |
| givenName | Yes | The user's first name. | |
| familyName | Yes | The user's last name. | |
| orgUnitPath | No | Target OU path (e.g. "/Sales/Staff"). | |
| primaryEmail | Yes | The primary email address for the new user. | |
| adminUserEmail | Yes | The administrator email to impersonate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavior: password is generated when omitted, returned only once. But doesn't mention error cases (e.g., duplicate email), rate limits, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the key action and a critical behavioral note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a creation tool but missing details like naming conflicts, default OU if not specified, and response structure (no output schema provided).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 7 parameters with descriptions (100% coverage). Description adds value by explaining the behavior of 'password' parameter (generation, one-time return).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Creates a new user account') and the resource ('in the Google Workspace directory'), distinguishing it from sibling tools like 'gam_admin_print_users' or 'gam_admin_update_ou'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or conditions for usage. Description lacks context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists active members of a group, paginating until exhaustion.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json | |
| groupEmail | Yes | The target Google Group email address. | |
| adminUserEmail | Yes | The administrator email to impersonate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the pagination behavior ('paginating until exhaustion'), which is a key behavioral trait. However, it does not mention permissions, rate limits, or whether the tool only lists active members (vs. all members). For a read operation, this is adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose and a key behavior (pagination). It is concise without being under-specified. It earns a high score for efficiency, though it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return format or content structure. It does not. While it mentions pagination, it omits what the output contains (e.g., list of emails, metadata). For a listing tool with a sibling like gam_admin_print_groups (which likely outputs structured data), this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 67% of parameters with descriptions (adminUserEmail and groupEmail). The description adds no additional meaning for any parameter; it does not explain the format parameter or any format-related behavior. With moderate schema coverage, the description fails to compensate for the undocumented parameter or add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists active members of a group', which specifies the verb and resource. It also mentions pagination behavior ('paginating until exhaustion'), distinguishing it from sibling tools like gam_admin_print_groups (list groups) and gam_admin_sync_group_members (sync members). It could be more explicit about the distinction but is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for listing active group members, providing context for when to use it. However, it does not explicitly state when not to use it or mention alternatives. No prerequisites or exclusions are given, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists groups, paginating until exhaustion (capped at MAX_PAGES_LIMIT pages).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json | |
| adminUserEmail | Yes | The administrator email to impersonate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination behavior and a cap (MAX_PAGES_LIMIT), but lacks information on authentication requirements or potential side effects. With no annotations, the description partially addresses transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one sentence with no extraneous information. The main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple listing tool with only two parameters. Mentions pagination and cap, which are crucial. However, lacks description of return values, partially mitigated by no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides good coverage (50%) with descriptions for adminUserEmail and default for format. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('lists groups') and includes an important detail about pagination and a cap, differentiating it from sibling tools like gam_admin_print_group_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as a search or filter. Lacks context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists user profiles, paginating until exhaustion (capped at MAX_PAGES_LIMIT pages).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Admin SDK user list query (e.g. "name:John*"). | |
| format | No | json | |
| orgUnitPath | No | Filter by OU path (e.g. "/Sales"). | |
| adminUserEmail | Yes | The administrator email to impersonate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It covers pagination and a page limit, but does not disclose return structure, required permissions, or other behavioral traits like rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It directly states the core function and important pagination detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks details on return values, query usage, required permissions, and the actual page limit. It is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 parameters described). The description adds no parameter-level information beyond the schema, which is adequate for medium-high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists user profiles' which clearly indicates the tool's function. It includes pagination behavior, but does not explicitly differentiate it from sibling tools like gam_admin_print_group_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions automatic pagination with a cap, providing guidance on usage scope. However, it does not specify when not to use this tool or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synchronizes a Google Group's membership against a target list, adding/removing concurrently.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | Compute diffs without writing (default true). | |
| groupEmail | Yes | The target Google Group email address. | |
| targetMembers | Yes | The complete desired list of member emails. | |
| adminUserEmail | Yes | The administrator email to impersonate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavior (add/remove concurrently) but lacks detail on idempotency, failure modes, permissions, and the dryRun parameter (which is critical for safety). No annotations exist to supplement, so the description carries the burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 11 words) and front-loaded. It immediately communicates the tool's purpose without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the tool returns or error behavior. It covers the main function but is incomplete for a sync tool that likely produces diffs or status messages. The dryRun parameter's output is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are described in the schema. The description adds no additional parameter context beyond the schema. It does not explain how targetMembers relates to existing membership or the role of adminUserEmail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'synchronizes', the resource 'Google Group's membership', and the method 'adding/removing concurrently'. It differentiates from sibling tools like gam_admin_print_group_members (read-only) and gam_admin_create_user (user creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, idempotency, or cautionary notes. Usage is implied as a bulk sync operation but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves a user to a different OU or re-parents an OU. The caller MUST set targetType explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | Validate without moving (default true). | |
| targetKey | Yes | The user primaryEmail or the OU path (e.g. "/Sales"). | |
| targetType | Yes | Whether `targetKey` identifies a user or an OU path. | |
| orgUnitPath | Yes | Destination OU path (e.g. "/Sales/Staff"). | |
| adminUserEmail | Yes | The administrator email to impersonate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It correctly states the primary actions (move/re-parent) but fails to mention the dryRun parameter's default behavior, required permissions, reversal possibility, or side effects. The transparency is adequate for basic understanding but lacks depth expected for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no wasted words. It front-loads the purpose and immediately follows with a critical usage note. Every sentence earns its place, and the format is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 4 required, no output schema, and no annotations, the description provides a minimal but functional overview. It lacks details about return values, error conditions, dry run validation, or the difference between moving a user and re-parenting an OU. Adequate for basic understanding but leaves gaps for an agent needing full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds no extra parameter meaning beyond what the schema already provides (e.g., targetType requirement). It merely reiterates a requirement already present in the schema; no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does two specific operations: moves a user to a different OU or re-parents an OU. It uses specific verbs ('Moves', 're-parents') and resources ('user', 'OU'), making it distinct from sibling tools which handle user creation, group management, or file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear requirement ('caller MUST set targetType explicitly'), which guides correct usage. While it doesn't explicitly state when not to use or name alternatives, the sibling tools are sufficiently different to imply this is the correct tool for OU moves. Lacks explicit exclusions but is adequate for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Memory-safe Drive permissions audit. Streams results to a local file under GAM_MCP_OUTPUT_DIR (or cwd if unset).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional server-side query filter. | |
| format | No | csv | |
| corpora | No | Drive v3 corpora scope. Use "allDrives" to include Shared Drives. | user |
| userEmail | Yes | Impersonation subject (Drive owner). | |
| outputPath | Yes | Output file path, RELATIVE to GAM_MCP_OUTPUT_DIR (or cwd). Symlinks rejected. | |
| filterOwner | No | ||
| oneItemPerRow | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions 'memory-safe' and 'streams' implying non-destructive read operation, and output path behavior. However, lacks explicit statement on whether it modifies data, and does not disclose required permissions or side effects. Behavior of filterOwner default is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Could be more structured but efficient. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, the description is insufficient. It explains output destination but not output format details, nor behavior of key parameters. Fails to provide complete understanding of tool's functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, so description should provide additional parameter context. It does not discuss any parameters. The description adds no value beyond schema for parameters like query, format, corpora. Users need to rely on schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a Drive permissions audit that streams results to a file. The verb 'audit' is specific, and resource 'Drive permissions' is clear. It distinguishes from sibling tools like gam_drive_list_files which lists files, not permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like gam_export_audit_to_sheets. No prerequisites or exclusions mentioned. Agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Drive file metadata matching a server-side query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Drive v3 search syntax. | |
| format | No | json | |
| corpora | No | Drive v3 corpora scope. Use "allDrives" to include Shared Drives. | user |
| userEmail | Yes | Impersonation subject (Drive owner). | |
| maxResults | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description carries full burden for behavioral disclosure. It only states the basic function and mentions "server-side query," but fails to disclose pagination behavior (though maxResults and a limit of 1000 are in the schema), rate limits, authentication requirements beyond the userEmail parameter, or whether trashed files are included. The description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it lacks structure that could highlight key aspects (e.g., required parameters, pagination hints). It is appropriately sized for a simple tool but could be more informative without added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format (json/csv), pagination behavior, how to use the corpora parameter for shared drives, or that the userEmail is for impersonation. The 60% schema coverage partially compensates but the description itself is too sparse to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (three out of five parameters have descriptions). The description does not add meaning beyond what the schema provides; it only restates that the tool uses a "server-side query." For the two parameters without schema descriptions (format, maxResults), the description offers no clarification. Overall, it does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb "Lists", the resource "Drive file metadata", and the condition "matching a server-side query." This distinguishes the tool from siblings like gam_drive_audit_permissions and gam_gmail_search_messages, which operate on different resources or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring a user email for impersonation, or when to prefer this over other list tools. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Streams a local CSV audit to a Google Sheet tab in safe 2000-row chunks. CSV path must live under GAM_MCP_OUTPUT_DIR.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | ||
| csvPath | Yes | Source CSV path, RELATIVE to GAM_MCP_OUTPUT_DIR (or cwd). | |
| sheetName | Yes | Target sheet tab name. | |
| userEmail | Yes | Impersonated Sheet editor. | |
| clearSheet | No | ||
| spreadsheetId | Yes | Target Google Spreadsheet ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides some behavioral details (chunking for safety, path constraint) but omits side effects like sheet clearing (clearSheet default true), permissions needed, and success/failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks context about return values, required parameters (only csvPath mentioned), and overall flow. Given no output schema and a complex input schema with 6 params, more context is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (mid-range). Description adds context for csvPath (must be under GAM_MCP_OUTPUT_DIR) but does not elaborate on other parameters like dryRun, clearSheet, userEmail, etc. Marginal value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it streams a local CSV audit to a Google Sheet tab in chunks, with a specific path constraint. Distinct from sibling tools focused on user/group management or drive operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not discuss prerequisites, context for chunking, or cases where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purges emails matching a query in bulk. Defaults to dry-run with samples.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Gmail search query targeting candidate emails. | |
| dryRun | No | ||
| userEmail | Yes | Mailbox to clean (also the DWD subject). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the destructive nature and the dry-run default, which is critical. However, it does not mention permissions or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the verb and key behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being brief, the description omits important details for a destructive tool: confirmation steps, limit on deletion count, required permissions, and whether deletion is permanent (trash vs. hard delete). Given no output schema or annotations, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params have descriptions). The description adds value by stating the dryRun default behavior, which complements the schema. No additional info for query or userEmail beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool purges emails matching a query in bulk, with a default dry-run. It distinguishes from sibling tools like gam_gmail_get_message and gam_gmail_search_messages by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (bulk deletion) and mentions dry-run safety, but does not explicitly contrast with alternatives like searching first or using other deletion methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches details of a single email including recursively decoded body content.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The unique Gmail message ID. | |
| userEmail | Yes | Mailbox to query (also the DWD subject). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions 'recursively decoded body content' which adds behavioral info, but does not disclose other traits like required permissions or whether it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 16 words, front-loaded with key action. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description hints at return content (details including body). For a simple fetch tool with 2 parameters, it is fairly complete, though it could specify more about returned fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond what schema already provides for userEmail and messageId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches details of a single email, using specific verbs and resource. It distinguishes from sibling tools like gam_gmail_search_messages (finds multiple) and gam_gmail_bulk_delete (modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No prerequisites, when-not-to-use, or comparisons with siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches a mailbox and returns metadata + snippets. The mailbox owner (userEmail) is the DWD impersonation subject.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Gmail search syntax (e.g. "from:payroll subject:urgent"). | |
| format | No | json | |
| userEmail | Yes | Mailbox to search (also the DWD subject). | |
| maxResults | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that userEmail is the DWD impersonation subject, which is behavioral context beyond the schema. However, it does not mention read-only nature, rate limits, or any other behavioral traits, and no annotations are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose and a key behavioral note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter schema, no output schema, and no annotations, the description lacks details about return format structure, pagination, required scopes, or error conditions. 'Metadata + snippets' is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (query and userEmail have schema descriptions). The description adds a brief note about userEmail's role (DWD), but this is already in the schema. No additional meaning is added for format or maxResults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (searches) and resource (mailbox) and output (metadata + snippets). It is distinct from sibling tools like gam_gmail_get_message, but does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives. There is no mention of prerequisites, when not to use, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a worksheet range to feed administrative execution scripts.
| Name | Required | Description | Default |
|---|---|---|---|
| range | Yes | A1 notation range (e.g. "Sheet1!A:C"). | |
| userEmail | Yes | Impersonated reader. | |
| spreadsheetId | Yes | Spreadsheet ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states 'reads' implying a safe, read-only operation, but does not disclose any behavioral traits such as permission requirements, rate limits, or that it impersonates a user via 'userEmail'. This is minimal for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb 'Reads'. No unnecessary words. It is concise, though it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three required parameters, no output schema, and no annotations, the description is adequate but not comprehensive. It explains the primary purpose but lacks details on return format, error conditions, or required permissions. For a simple read operation, it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema provides. It mentions 'worksheet range', which aligns with the 'range' parameter, but does not clarify the format or usage of other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a worksheet range and its purpose to feed administrative scripts. The verb 'reads' and resource 'worksheet range' are specific. However, it does not explicitly distinguish from sibling tools, though the context implies it is for reading rather than mutating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or avoid this tool. The description does not mention alternatives or conditions. The phrase 'to feed administrative execution scripts' hints at a specific use case but does not provide explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0gam_admin_create_usergam_admin_print_group_membersgam_admin_print_groupsgam_admin_print_usersgam_admin_sync_group_membersgam_admin_update_ougam_drive_audit_permissionsgam_drive_list_filesgam_export_audit_to_sheetsgam_gmail_bulk_deletegam_gmail_get_messagegam_gmail_search_messagesgam_read_admin_sheetEach tool targets a distinct Google service and operation (Admin, Drive, Gmail, Sheets), with no overlapping functionality. Tools like `gam_admin_print_groups` and `gam_admin_print_group_members` are clearly differentiated by object type.
All tools follow a consistent `gam_<service>_<action>[_<object>]` pattern in snake_case, using descriptive verbs like create, print, sync, update, audit, list, export, and read.
With 13 tools covering Admin, Drive, Gmail, and Sheets operations, the tool count is well-scoped for a Google Workspace administration server—neither too sparse nor overly heavy.
The tool set covers common admin tasks like user creation, group management, drive auditing, and Gmail operations. Minor gaps exist, such as missing user deletion or group creation, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/undeadindustries/gam-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
