This server provides minimal Google Workspace functionality for Gmail, Drive, Docs, and Sheets across two fixed accounts (personal and professional).
Gmail:
Search messages using Gmail query syntax, with pagination and result limits.
Read the decoded body of a single message or an entire thread.
Send new emails (as drafts or immediately) with To, CC, BCC, subject, and body; optionally reply to a thread.
Modify labels (add/remove) on messages or threads to archive, mark read/unread, star, or trash.
Google Drive:
Search files and folders using Drive query syntax with optional MIME type filtering and pagination.
Retrieve file contents: exports Google Docs as Markdown, Google Sheets as CSV, and text files as raw.
Batch update files: move (change parent), rename, or trash multiple items at once.
Create new folders, optionally nested under a parent folder.
Google Docs:
Create a new Doc from Markdown content, with a title and optional parent folder.
Update a Doc by appending text or performing a find-and-replace on all occurrences of a string.
Google Sheets:
Read values from a specified A1 range.
Write or append a 2D array of values to a range; supports formula input via USER_ENTERED mode.
Constraints:
No permanent deletion – only trashing is available.
Every tool requires specifying the account parameter (personal or professional).
Calendar event creation is listed in the README but is not currently available in the server schema.
Provides tools for searching, reading, sending, and modifying emails (labels, archive, read state, star, trash).
Provides tools for creating documents from Markdown and updating (append text, replace all occurrences).
Provides tools for searching files, getting content (Docs as Markdown, Sheets as CSV, text files), updating (move, rename, trash), and creating folders.
Provides tools for reading and writing to A1 ranges (write or append).
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., "@gws-mcp find emails from Alice in my work Gmail"
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.
The OAuth app behind this repo is published butnot verified by Google, and it serves only my own two Google accounts. The consent screen shows the "Google hasn't verified this app" warning by design, and its unverified user cap leaves no room for anyone else. To run this yourself, create your own Google Cloud project and Desktop OAuth client with the same three scopes. The setup section below covers every step, and the account emails come from environment variables, never from code. If enough demand shows up I may put the app through Google's verification process. Open an issue if you want that.
Minimal Google Workspace MCP server for Claude Code. Gmail, Drive, Docs,
Sheets, and Calendar across two fixed accounts. Thirteen tools, roughly
1,750 schema tokens.
It replaces workspace-mcp, whose same-service surface measured 65 tools and
roughly 28,000 tokens.
Tool | Purpose |
| Gmail query syntax in, message metadata out |
| Decoded body of one message or a whole thread |
| Send or draft, |
| Label names on messages or threads, covers archive, read state, star, trash |
| Drive query plus MIME filter |
| Docs export as Markdown, Sheets as CSV, text files raw |
| Batch move, rename, trash. Per-file results |
| New folder under a parent |
| New Doc from Markdown |
| Append text or replace all occurrences |
| A1 range in, values out |
| Write or append to an A1 range |
| New event, all-day or timed, optional RRULE recurrence and popup reminder |
Every tool takes account, an enum of personal and professional. The
alias-to-email map comes from GWS_MCP_PERSONAL_EMAIL and
GWS_MCP_PROFESSIONAL_EMAIL, set in .envrc.
No tool can permanently delete anything. Trashing is the only removal the
tool surface performs. The stored token itself carries the full drive
scope, which Google classifies as restricted, so guard the token store, and
know that the credential could do more than the tools allow.
Related MCP server: Google Workspace MCP
Create a project at https://console.cloud.google.com/projectcreate. The string "google" is banned in project IDs and app names.
Enable five APIs: Gmail, Google Drive, Google Docs, Google Sheets, Google Calendar.
Google Auth Platform: External audience, no test users.
Publish to Production immediately. A Testing-status app expires every refresh token 7 days after consent.
Create a Desktop-app OAuth client. Copy the client ID and secret.
Do not submit the app for verification. The unverified-app warning at consent time is expected.
The client credentials live in safetybox:
gwsmcp/google-client-id -> GWS_MCP_GOOGLE_CLIENT_ID
gwsmcp/google-client-secret -> GWS_MCP_GOOGLE_CLIENT_SECRET.envrc is not committed. Copy .envrc.example, fill in the two account
emails, then run direnv allow. The safetybox line loads both client
credentials with one identity unlock, reading the passphrase from passage
via secret-get. Only the auth CLI reads these variables. OAuth tokens
land in ~/.local/share/gws-mcp/tokens.db, file mode 0600, directory
0700, never in the repo.
uv sync
uv run gws-mcp-auth personal
uv run gws-mcp-auth professionalEach run opens a browser. Sign in as the matching account and click through Advanced at the unverified-app warning. The CLI verifies the signed-in address against the alias and refuses to save a mismatch.
A scope added to SCOPES never reaches an already-stored grant. Re-run
gws-mcp-auth <alias> for each account, otherwise the new tool fails
with an insufficient-scope 403.
Then verify with the live read-only smoke script:
uv run python scripts/smoke.pyclaude mcp add gws-mcp -s user -- uv run --directory /Users/samuelstidham/code/samuel-stidham/gws-mcp gws-mcpuv run pytestThe suite fakes every Google endpoint with respx and never touches the live APIs. It covers account routing, the single-refresh 401 rule, rate-limit backoff, MIME decoding, label resolution, batch Drive semantics, Sheets append, protocol round-trips, stdout cleanliness, and the schema budget.
Measure the schema at any time:
uv run python scripts/measure_schema.py
uv run python scripts/measure_schema.py --probe uvx workspace-mcp --tools gmail drive docs sheetsThe probe spawns the child with the MCP SDK's safe environment allowlist,
so no secret from your shell reaches it. Pass --env KEY=VALUE for
anything the probed server genuinely needs.
A Google password change revokes that account's refresh token. Re-run
gws-mcp-auth <alias>. A running server picks up the new grant on its
next refresh, no restart needed.
A refresh token unused for six months expires.
The server refreshes once on 401 and then fails with the exact re-auth command in the error message. A dead grant fails a whole batch immediately instead of retrying per item.
sheets_write uses USER_ENTERED, so a value starting with = becomes
a live formula. That is deliberate, and it means untrusted text should
not be written to sheets verbatim.
Create a Google Doc from Markdown, optionally in a folder.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| account | Yes | ||
| markdown | Yes | ||
| parent_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the action, not permissions, error conditions, 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?
The description is one short, clear sentence with no redundancy. However, it could include more detail without losing 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 4 parameters, 0% schema coverage, and an output schema, the description is insufficient. It omits many important details about inputs and output.
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 0%, and the description only hints at parent_id ('optionally in a folder'). It does not explain account enum, markdown format, or title constraints.
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 'Create' and resource 'Google Doc from Markdown' with an optional folder. It distinguishes from siblings like docs_update and drive_folder_create.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like docs_update or drive tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append text to a Doc, or replace every occurrence of find with replace.
| Name | Required | Description | Default |
|---|---|---|---|
| find | No | ||
| account | Yes | ||
| replace | No | ||
| append_text | No | ||
| document_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the two actions but fails to mention important behavioral traits like whether find/replace is destructive, whether both operations can be combined, or required permissions. No warnings or side effects are noted.
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 front-loads the action. It is concise but omits necessary details. While efficient, it sacrifices completeness for 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's complexity (two modes, 5 parameters), the description is insufficient. It does not explain the conditional logic, error handling, or return value (though an output schema exists). The tool is not fully specified for an agent.
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 0%, so the description must compensate. It mentions 'append text' and 'find/replace' but does not explain the parameters (e.g., that find is needed for replace, or the role of append_text). It adds minimal meaning beyond parameter names.
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 the tool appends text or performs find-replace, which is specific. However, it does not differentiate from sibling tools like docs_create, and the dual functionality could be clearer regarding when each mode applies.
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 versus alternatives (e.g., docs_create for new docs, or other tools). The description does not specify prerequisites or conditions for using the two modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a folder, optionally under a parent.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| account | Yes | ||
| parent_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal behavioral disclosure: only states it creates a folder. No information on permissions, side effects, or error behavior. Since annotations are absent, the description carries the burden.
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 at 7 words, front-loaded with the action. However, it is under-specified for the number of parameters, but the score reflects its 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?
Incomplete for a 3-parameter creation tool with no annotations. Though an output schema exists, the lack of parameter semantics and behavioral details makes it inadequate.
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 0%, yet the description only hints at parent_id via 'optionally under a parent'. Required parameters 'account' (enum) and 'name' are completely unexplained.
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 action 'Create a folder' and the optional parent clause, distinguishing it from sibling tools like drive_search and drive_update.
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 (e.g., drive_update for modifying folder properties), nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a file: Docs export as Markdown, Sheets as CSV, text files raw.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | ||
| file_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses export behavior for Docs, Sheets, and text files but omits details like read-only nature, authentication, error handling, or behavior for unsupported file types.
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?
A single sentence with no wasted words, front-loaded with the key purpose 'Fetch a file'. Extremely concise and well-structured for quick comprehension.
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?
While output schema exists, the description covers only Docs, Sheets, and text files, leaving gaps for other file types (e.g., images, PDFs). It also doesn't specify response format or limitations, so completeness is moderate.
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 0%, and the description adds no meaning to the two parameters (account, file_id). It does not explain the account enum values or the file_id's role, leaving the schema to stand 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?
The description clearly states 'Fetch a file' as the action, specifies export formats for different file types (Docs as Markdown, Sheets as CSV, text files raw), and distinguishes from sibling tools like drive_search and drive_update.
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 usage for retrieving file content with specific export formats, but does not explicitly state when not to use it (e.g., for metadata retrieval or binary files) nor mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Drive with Drive query syntax, optional MIME filter.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| account | Yes | ||
| mime_type | No | ||
| page_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits such as pagination (page_token), rate limits, authentication needs, result ordering, or whether the search is scoped to user's Drive. The description is too minimal for a tool that likely returns a list of files.
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, no wasted words. It front-loads the main purpose. However, could be expanded slightly to cover the account parameter or pagination without losing 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 the complexity (4 parameters, search tool with output schema), the description is insufficient. It omits how to use page_token (pagination), the significance of account, and any search result format. While output schema covers return values, the description should guide parameter usage.
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 description adds meaning to 'query' (Drive query syntax) and 'mime_type' (optional MIME filter), but does not explain 'account' (required enum with two options) or 'page_token' (pagination). With 0% schema coverage, it partially compensates but misses important 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 the tool searches Drive using query syntax and optionally filters by MIME type. It distinguishes from sibling tools like drive_get (single file retrieval) and drive_folder_create (creation). However, it doesn't specify the return type or scope (e.g., list of files matching query).
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 like drive_get or gmail_search. It doesn't mention prerequisites (e.g., account required) or scenarios where query syntax is appropriate. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move (parent_id), rename (name), or trash (trashed) files and folders; reports per file.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| account | Yes | ||
| trashed | No | ||
| file_ids | Yes | ||
| parent_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that multiple operations can be performed in one call and that output reports per file. However, it does not mention required permissions, atomicity, error handling, or rate limits.
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?
One sentence with all key information front-loaded. No redundancy or filler. Every word adds value.
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, 2 required, and an output schema, the description is incomplete. It does not explain required parameters (account, file_ids) or the output structure. For a multi-action tool with sibling context, more information would be beneficial.
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 0%, so description must compensate. It explains three parameters (parent_id, name, trashed) but fails to describe the required parameters (account, file_ids). Account is an enum but not clarified. Partial 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?
Description clearly states three specific actions (move, rename, trash) and maps each to a parameter (parent_id, name, trashed). It also indicates per-file reporting. This distinguishes it from siblings like drive_search or drive_get.
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. For example, if a user wants to trash a file, they might not know whether to use this or a hypothetical other tool. No exclusions or preconditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or remove labels by name on messages or threads; covers archive, read state, star, trash.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | ||
| add_labels | No | ||
| thread_ids | No | ||
| message_ids | No | ||
| remove_labels | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It mentions that the tool 'covers' special states like archive, read state, star, and trash, which are implemented as labels, but does not detail permissions, rate limits, error behavior, or what happens if labels are missing. Some transparency is present, but significant gaps remain.
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 of 15 words, which is very concise. However, it sacrifices detail that could be provided in a slightly longer, structured format. It earns its place but leaves out parameter information that would improve usability.
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?
The tool has a moderate number of parameters (5) and an output schema (not shown but present). The description does not explain the relationship between thread_ids and message_ids, the behavior when both are provided, or the necessity of the account parameter. While the output schema can handle return values, the description's gaps in parameter semantics and usage reduce completeness for an agent.
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 has 0% description coverage (only titles, no descriptions). The tool description does not elaborate on any parameter beyond the phrase 'by name', which hints at label names but does not explain the format of add_labels and remove_labels, the distinction between thread_ids and message_ids, or the requirement of the account parameter. The description adds minimal semantic value beyond the schema titles.
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 verb ('Add or remove labels') and the resource ('messages or threads'). It also enumerates covered actions (archive, read state, star, trash), which differentiates it from sibling tools like gmail_search, gmail_read, and gmail_send.
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 that the tool is for label modification, but it does not explicitly state when to use it versus alternatives, nor does it provide when-not or exclusion criteria. The usage context is only implied, offering no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the decoded body of one message or a whole thread; pass exactly one id.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | ||
| thread_id | No | ||
| message_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses it is a read operation ('Read the decoded body') and the one-id constraint, but lacks details on authentication, rate limits, or behavior when both ids 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 a single, front-loaded sentence with no wasted words, but its brevity sacrifices completeness, especially given the lack of schema descriptions.
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 three parameters and missing schema descriptions, the description adequately conveys the core functionality but omits details about the required account parameter and the precise selection logic for thread_id vs message_id.
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 0%, and the description only partially explains parameters (implies thread_id for thread, message_id for message) but leaves account unexplained and does not clarify the relationship between the two optional ids.
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 reads the decoded body of one message or a whole thread, distinguishing it from sibling tools like gmail_search, gmail_send, and gmail_modify.
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 advises to pass exactly one id, implying a constraint on parameter usage, but does not explicitly specify when to use this tool over alternatives or mention prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Gmail with Gmail query syntax; returns message metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| account | Yes | ||
| page_token | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'returns message metadata', which implies a read-only operation without side effects, but does not explicitly confirm non-destructiveness. For a search tool, the implicit safety is adequate, but lacks details on pagination behavior or rate limits.
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 8-word sentence, which is concise but under-specified. It front-loads the core function but omits crucial details about parameters and usage. It is not verbose, but the brevity sacrifices completeness.
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 having an output schema (which reduces the need to describe return values), the description is incomplete for a 4-parameter tool with no schema descriptions. It lacks guidance on pagination, account selection, and result limits. The sibling tools are not contextualized.
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 0%, so the description must compensate. It only hints at the 'query' parameter via 'Gmail query syntax', but does not explain 'account', 'page_token', or 'max_results'. The agent gets no help understanding the purpose of these parameters beyond their names and types.
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 'Search' and the resource 'Gmail', and specifies 'with Gmail query syntax' and 'returns message metadata'. It distinguishes the tool from siblings like gmail_read (reads a specific message) and gmail_send by implying a batch search capability, though it does not explicitly name alternatives.
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 no guidance on when to use this tool versus alternatives like gmail_read or drive_search. It does not mention prerequisites, when not to use it, or specific scenarios. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email, or save a draft; thread_id makes it a reply.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | ||
| to | Yes | ||
| bcc | No | ||
| body | Yes | ||
| draft | No | ||
| account | Yes | ||
| subject | Yes | ||
| thread_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: sending an email versus saving a draft, and using thread_id to reply. However, with no annotations provided, it does not cover other behavioral aspects such as authentication, rate limits, or irreversible actions, which could be important for an agent.
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 is direct and front-loaded. It includes the essential information without any extraneous text, earning its place efficiently.
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 8 parameters (4 required) and zero schema descriptions, the description is insufficient. It does not explain the account enum, the effect of setting draft=true, or the return value. An output schema exists but is not referenced, so the agent lacks guidance for complete usage.
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 0%, so the description must add meaning. It only hints at two parameters: draft (via 'save a draft') and thread_id (via 'makes it a reply'). Other parameters like to, subject, cc, bcc, and account are not described, leaving the agent to infer from parameter names.
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's purpose: sending an email or saving a draft, with thread_id enabling replies. This distinguishes it from sibling tools like gmail_search, gmail_read, and gmail_modify, which handle different 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?
The description implies usage for sending or drafting emails, but does not explicitly state when to use this tool over alternatives or provide any exclusions. The sibling context helps, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read values from an A1 range.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | ||
| a1_range | Yes | ||
| spreadsheet_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does not disclose any behavioral traits such as rate limits, handling of large ranges, or behavior with empty cells. It is too minimal for safe agent execution.
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—only one sentence. While this is efficient, it sacrifices necessary detail about parameters and usage, making it less helpful than a slightly longer description would be.
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?
With 3 required parameters, no annotations, and no schema descriptions, the description is insufficient. It does not explain how to specify the range format or which account to use, nor does it mention the output schema (though one exists). Contextual completeness is low.
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 has 0% description coverage, and the description only mentions 'A1 range' (matching the parameter name). It does not explain 'account' (enum with values 'personal'/'professional') or 'spreadsheet_id'. The description adds very little beyond the parameter names.
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 reads values from an A1 range, which is specific enough to distinguish from other tools like 'sheets_write'. However, it does not elaborate on the type of values or output format.
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. Sibling tools exist (e.g., gmail_, drive_), but no explicit when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write values to an A1 range, or append them as new rows.
| Name | Required | Description | Default |
|---|---|---|---|
| append | No | ||
| values | Yes | ||
| account | Yes | ||
| a1_range | Yes | ||
| spreadsheet_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'write' and 'append' without detailing behavioral traits like overwrite behavior, row creation, or permission needs. For a mutation tool, this lacks disclosure.
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 concise (one short sentence) but front-loads the main action. However, it omits critical details, making it acceptable but not optimally informative.
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 having an output schema, the description lacks completeness for a write tool: no mention of error conditions, append behavior details, or prerequisites. Five parameters with four required are only vaguely addressed.
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 0%, but description only names 'A1 range' and 'values' implicitly. It does not explain the format of a1_range, meaning of append (true/false), or structure of values, leaving agents to infer from schema 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?
The description clearly states the action ('Write values') and the resource ('an A1 range' or 'append them as new rows'), distinguishing it from the only sibling sheets tool 'sheets_read' which is for reading.
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 write vs append, or when to avoid this tool. With no sibling write tools, the omission is less critical but still a gap for an agent deciding between operations.
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.
v0.1.0docs_createdocs_updatedrive_folder_createdrive_getdrive_searchdrive_updategmail_modifygmail_readgmail_searchgmail_sendsheets_readsheets_writeAll tools are clearly separated by service (gmail, drive, docs, sheets) and action, with no overlap. Gmail and Drive have their own search tools, and each service's operations are distinct and unambiguous.
All tools follow a consistent pattern of {service}_{action} in snake_case (e.g., drive_search, sheets_write). Even drive_folder_create uses a clear verb-noun structure. No mixed conventions.
With 12 tools, the server covers core operations for Gmail, Drive, Docs, and Sheets without being overly large. Each tool serves a clear purpose and the count fits the domain well.
The tool set covers essential CRUD operations: search, read, create, update for most services. Minor gaps exist (e.g., no create spreadsheet, no hard delete), but common workflows are supported, especially via modificational labeling and trashing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Streamable HTTP MCP server for Google Calendar and Sheets with OAuth login.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
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/samuel-stidham/gws-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
