mcp-google-workspace

by guinacio

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.10
Disambiguation3/5
Most tools have distinct purposes, but the file tools overlap: files_list_files and files_list_files_page both list files, and files_file_manager is a catch-all that could confuse selection. The meta-tools call_tool and search_tools also add ambiguity about when to use direct vs meta tools.
Naming Consistency3/5
Naming is mostly verb_noun with underscores, but there are inconsistencies: some tools use google_workspace, others just workspace, and the files_ prefix is applied inconsistently (files_file_manager is a noun phrase, not a verb). The files_list_files_page variant deviates from the simple verb_noun pattern.
Tool Count4/5
15 tools is within the expected range, but the set includes redundant file listing tools and generic meta-tools (call_tool, search_tools) that could be considered unnecessary. Still, the count is reasonable for the scope.
Completeness2/5
The tool surface lacks common Google Workspace operations like sending email, creating events, or reading contacts beyond search. It focuses on connection management, search, and a generic action mechanism, leaving significant gaps for an agent trying to perform typical Workspace tasks.
Average 3.6/5 across 15 of 15 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims 'Upload and manage files', implying write operations, but annotations have readOnlyHint=true, which indicates a read-only tool. This is a clear contradiction. No additional behavioral context is provided beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (two sentences) but lacks essential details and is front-loaded with the purpose. However, it is too vague and does not earn its place due to missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and no parameters, the description is contradictory to annotations and fails to explain how the tool works or what its behavior is. It is not complete enough for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the description does not explain how to specify files for upload (e.g., via drag-and-drop). The phrase 'Drop files here' is insufficient for an AI agent to understand the mechanism.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Upload and manage files' which indicates a broad file management purpose, but 'manage' is vague and does not clearly distinguish from sibling tools like files_list_files which handle specific list operations. The purpose is somewhat clear but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 files_list_files. The description does not provide context for appropriate usage or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Remove' which implies destructive action, but annotations set destructiveHint=false. Additionally, description restricts to 'only the authenticated user's' credentials (scoped), while annotations set openWorldHint=true, suggesting broader effects. This direct contradiction warrants a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with precise, front-loaded information. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool that removes credentials, the description lacks context on side effects, reversibility, or output. Even with output schema present (not shown), the brevity leaves agents underinformed about the operation's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single boolean parameter 'confirm'. The description adds no additional meaning beyond the schema, achieving baseline score for well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove' and the resource 'authenticated user's encrypted Google OAuth credentials', distinguishing it from sibling tools like connect_google_workspace or get_google_connection_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context. It only states what it does without directing agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral details beyond what annotations provide, missing an opportunity to explain scope or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it could be slightly more informative without breaking conciseness, e.g., mentioning the output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, presence of an output schema, and rich annotations, the description is adequate. No major gaps, though it could mention that it returns boolean or status details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single optional parameter 'capability' is fully described in the schema). The tool description does not add any parameter-specific meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Report' and resource 'whether... connected Google Workspace'. Distinguishes from siblings like `connect_google_workspace` and `disconnect_google_workspace` which perform actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 `get_workspace_capabilities` or `search_workspace`. The description is too minimal to provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, read-only, idempotent behavior. The description adds no additional behavioral context (e.g., query syntax, result aggregation, or rate limits), missing an opportunity to add value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. Every word contributes to the purpose, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full output schema and rich annotations, the description is minimally adequate. However, it lacks contextual details such as expected result structure or query format nuances, leaving some information gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description does not add parameter-specific details beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and identifies the resources (Drive files, contacts, Gmail IDs) through a unified entry point. It does not explicitly differentiate from sibling tools but provides a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a cross-service search use case but does not provide explicit guidance on when to use this tool versus alternatives like search_tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that files are listed with metadata, but doesn't disclose behavior like ordering or bulk retrieval limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 5 words, with no wasted content. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the main function. However, it could mention that results are not paginated (given the sibling 'files_list_files_page').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, schema coverage is 100%. The description implies no filtering by stating 'all uploaded files', which adds sufficient meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists uploaded files with metadata, using a specific verb and resource. However, it does not differentiate from the sibling 'files_list_files_page' which likely provides paginated results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'files_list_files_page' or 'files_file_manager'. There is no context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context beyond 'page through' and avoiding unbounded results, but does not explain pagination mechanics (e.g., cursor usage) in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, containing zero wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and clear parameter descriptions, the description is mostly adequate. However, it does not mention that the response includes a cursor for subsequent pages, which would be helpful context for a pagination tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both 'limit' and 'cursor' having clear descriptions. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('page through') and resource ('uploaded files'), and distinguishes it from an unbounded catalog, which contrasts with the likely non-paginated sibling tool 'files_list_files'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need pagination to avoid an unbounded catalog, but it does not explicitly mention when to use this tool versus the sibling 'files_list_files' or provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide strong safety signals (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the description needs less behavioral disclosure. The description adds context about the content (namespaces, consent capabilities, file-transfer choices) but does not elaborate on broader behavior like openWorldHint implications or whether results are cached. Since annotations already communicate the safe, read-only nature, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without fluff or redundancy. Every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, a safe read-only annotation set, and an output schema present, the tool's description covers the necessary context well. The description outlines the three main output domains (namespaces, consent, file-transfer), which is sufficient guidance. Slightly more context about the tool's role in the overall workspace workflow could elevate it, but it is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool takes zero parameters, so the schema is trivially complete. The description compensates by enriching what the agent should expect in the output (namespaces, consent, file-transfer), which provides semantic value beyond the empty schema. A baseline of 4 for zero params is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Describe') and identifies a distinct resource ('workspace capabilities' including namespaces, consent capabilities, and file-transfer choices). It clearly distinguishes the tool's broad informational scope from sibling tools like get_google_connection_status or refresh_workspace_catalog, though it doesn't explicitly name a differentiating sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the go-to tool for exploring workspace capabilities, which is a natural fit given sibling tools like connect_google_workspace or prepare_workspace_action. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like requiring an active connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, open-world, non-idempotent behavior; the description adds value by noting the token is 'short-lived one-time' and that the action is 'consequential.' However, it does not disclose what 'preview' entails, token expiration mechanics, or potential side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose and key behavioral characteristic ('short-lived one-time commit token') efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a prepare/commit protocol, the description is complete enough to understand the basic function, but it omits mention of the companion 'commit_workspace_action' or any follow-up step. The output schema and annotations cover some context, but the protocol dependency is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage, including the enum list for 'tool_name' and a clear description for 'arguments.' The description adds no additional parameter details, so it does not exceed the baseline set by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Preview and bind one consequential action to a short-lived one-time commit token.' It uses specific verbs ('preview', 'bind') and identifies the resource (action, token), effectively distinguishing it from the sibling 'commit_workspace_action' by emphasizing the binding step rather than execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used as a preparatory step for a consequential action, but it does not explicitly state when to use it versus alternatives like 'commit_workspace_action' or 'call_tool.' There is no direct mention of a workflow or conditions that should trigger its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately describes the function (calling a tool with arguments) but does not disclose any behavioral traits such as side effects, authentication needs, or error handling. For a meta-tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a purpose: stating the action and providing usage context. There is no wasted text, and it is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema coverage and no output schema, the description covers the essential purpose and usage context. It could mention that the tool returns the called tool's output, but this is not critical for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds minimal new meaning beyond stating 'with the given arguments'. The baseline score of 3 is appropriate as the schema already documents both parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Call a tool by name with the given arguments' and provides context by tying it to tools discovered via search_tools. It distinguishes its purpose from sibling tools, which are specific file or workspace operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly advises to use this tool for executing tools found via search_tools. This gives clear when-to-use guidance, though it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the output format matches list_tools (implying a read operation), but does not mention any side effects, required permissions, or performance characteristics. Basic transparency is present but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no filler. The first sentence states the core purpose, and the second clarifies the output format. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema is present, the description does not need to detail return values. However, it omits information about result limits, sorting, or pagination. For a simple search tool with one parameter, completeness is nearly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description for the 'query' parameter already says 'Natural language query to search for tools'. The tool description adds no further semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search for tools using natural language' and specifies it returns matching tool definitions ranked by relevance, identical to list_tools. This clearly identifies the verb, resource, and output format, distinguishing it from sibling tools like 'search_workspace'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching tools but provides no explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. The agent must infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses atomic token consumption and execution of exact bound arguments, which adds behavioral context beyond the annotations (readOnlyHint=false, idempotentHint=false). It clarifies that the operation is one-time and the action is predetermined, complementing the annotation hints. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence that immediately conveys the core action. It has no redundant phrases and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is part of a two-phase workflow (prepare/commit), and the description does not explicitly situate it in that workflow. The parameter description and sibling list provide context, and the presence of annotations and output schema mitigates the need for further details, but the description alone is minimal and leaves workflow ordering implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter with a detailed description of the token's lifecycle. The main description only refers to it as a 'prepared action token' and mentions 'exact bound arguments', which adds minimal semantic value beyond the schema. Baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'consume' and 'execute' with a clear resource ('prepared action token' and 'exact bound arguments'). It distinctly describes the atomic consumption and execution, and differentiates this tool from its siblings, especially prepare_workspace_action, by focusing on the commit step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after preparation by referring to a 'prepared action token', but it does not explicitly state when to use it or provide exclusions. The parameter description in the schema gives additional context about the token's origin and expiry, but the main description lacks a direct 'use after prepare_workspace_action' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, establishing a safe read profile. The description adds the optional verification behavior via run_self_test, which complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the primary action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values. However, it lacks context about what the 'file-picker MCP Apps contract' entails and what the verification involves, leaving some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 100% of the single parameter. The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to describe the file-picker MCP Apps contract and optionally verify callbacks. The verb 'describe' and specific resource distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use this tool versus alternatives. The unique functionality implies when it's appropriate, but the description lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, meaning the tool modifies state and may have unknown side effects. The description discloses two OAuth modes but does not elaborate on side effects, credential storage, or the OAuth flow. It adds context beyond annotations but still leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the two modes of operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are present, the description covers the key behavioral modes. However, it lacks details on prerequisites (e.g., existing Google credentials), error conditions, and behavior when already connected. Still fairly complete for a connection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description does not add additional meaning to the single parameter 'capabilities' beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'connect' and the resource 'Google Workspace' via OAuth, and distinguishes two modes: local loopback OAuth and remote incremental-consent URL. This differentiates it from siblings like 'disconnect_google_workspace' and 'get_google_connection_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to connect to Google Workspace) but does not explicitly state when not to use or mention alternatives like 'refresh_workspace_catalog'. It provides clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so safety and side-effect profile is already provided. The description's word 'fresh' implies dynamic data, but it does not disclose any additional behavioral traits such as authentication needs, rate limits, or external calls. With annotations covering the basics, this is adequate but not enriched, scoring 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the core action and result. Every word earns its place, with no filler or repetition. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, a rich schema description, and an output schema, the description is mostly complete. It clearly conveys the tool's purpose and the schema explains the input. The only minor gap is that the description doesn't explicitly mention any preconditions like the URI belonging to the current workspace or that fresh metadata may require network access, but the output schema and annotations fill most needs. A 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'uri' parameter is already detailed, explaining it is a 'Stable Workspace resource URI previously returned in a tool response's resource field,' providing full meaning. The main description adds no parameter-specific information, and schema coverage is 100%, so the baseline of 3 applies. No extra credit is warranted for the description itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Resolve') and resource ('a stable Workspace URI') with an outcome ('fresh compact metadata'). This is distinct from sibling tools like search_workspace or refresh_workspace_catalog, which involve different operations. It fully explains what the tool does in one concise sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The schema parameter description adds context that the URI is 'previously returned in a tool response's resource field,' which strongly implies when to use this tool (when you have a resource URI from a prior call). However, the main description does not explicitly state alternatives or when not to use the tool, lacking direct comparison to search_workspace or refresh_workspace_catalog. Clear context with no exclusions justifies a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, so the description adds value by explaining the 'refresh' behavior and the trigger events. However, it doesn't detail what the refresh entails (e.g., updating tool definitions, clearing caches) or potential side effects, leaving some ambiguity despite annotations providing baseline context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. Every word is necessary, and there is no fluff. It efficiently conveys the purpose and trigger.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is largely complete. It clearly identifies the trigger context (consent/disconnection) and the action (refresh), which is sufficient for an agent to decide when to invoke it. Minor improvement could mention that the tool is typically used after workspace connection changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage. According to the rubric, baseline is 4 for 0 parameters. The description doesn't need to add parameter semantics since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: refreshing capability-aware tools triggered by Google consent or disconnection. It uses a specific verb (Refresh) and resource (capability-aware tools), and distinguishes itself from sibling tools like connect_google_workspace and disconnect_google_workspace by specifying the trigger events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: after Google consent or disconnection. This provides clear context, though it doesn't explicitly mention when not to use it or name alternatives. However, the trigger events naturally guide the agent to appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-google-workspace MCP server](https://glama.ai/mcp/servers/guinacio/mcp-google-workspace/badges/card.svg)](https://glama.ai/mcp/servers/guinacio/mcp-google-workspace)

Score Badge

Copy to your README.md:

[![mcp-google-workspace MCP server](https://glama.ai/mcp/servers/guinacio/mcp-google-workspace/badges/score.svg)](https://glama.ai/mcp/servers/guinacio/mcp-google-workspace)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/guinacio/mcp-google-workspace'

If you have feedback or need assistance with the MCP directory API, please join our Discord server