mcp-google-multi

by bakissation

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.0.0-semantically-released
Disambiguation5/5
Each visible tool has a clearly distinct purpose: one discover tool per Google service, plus generic API search/call and account list. There is no overlap or ambiguity among the 13 top-level tools.
Naming Consistency5/5
All tool names follow a consistent object_verb pattern using lowercase and underscores: gmail_discover, drive_discover, google_api_search, google_api_call, account_list. The naming convention is uniform and predictable.
Tool Count5/5
13 tools is well within the optimal range for a multi-service server. Each discover tool serves a distinct Google API, and the generic search/call tools provide a compact escape hatch, so every tool earns its place.
Completeness5/5
The discover tools expose comprehensive operation lists for major Workspace services, and google_api_search/google_api_call cover any REST method across a wider API set. Account management is also included, making the surface effectively complete with no dead ends.
Average 4.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 41 commits in the last 12 weeks
- Last stable release on August 10, 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a key behavioral disclosure: 'Operational drive tools are hidden until discovered — call this first,' which explains a non-obvious discovery behavior not captured by annotations. It does not mention return format or pagination, but for a simple list tool, this is acceptable.
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?
The description starts with a clear purpose but then includes an extremely long list of operation names. While the list is informative, it makes the description verbose and not concise. The key instructions ('call this first') are front-loaded, but the enumeration could be trimmed or moved to output examples for a cleaner structure.
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 (one optional param, no output schema), the description covers the essential context: it lists operations, explains the hidden-tool mechanism, and tells the agent to call the desired tool by name. It doesn't explain how the query parameter interacts with the list, but the schema covers that. Overall, it is sufficiently complete for the tool's purpose.
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 optional parameter 'query' with its description 'Keyword to filter the returned operations.' The tool description does not add any additional meaning to the parameter, so it relies entirely on the schema. This meets the baseline for parameter semantics.
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: 'List the available drive operations.' It uses a specific verb (List) and resource (drive operations), and distinguishes itself from sibling tools by focusing on the drive domain. It also explains the discovery mechanism, which clarifies its role.
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 provides explicit guidance on when to use this tool: 'call this first, then call the tool you need by name.' This clearly indicates it precedes other drive operations. While it doesn't explicitly list alternatives or when-not-to-use, the sibling discovery tools (e.g., gmail_discover) are implied by context, and the 'call this first' instruction is strong usage 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a key behavioral trait: operational meet tools are hidden until discovered, requiring this tool to expose them. This goes beyond the annotations and explains the discovery mechanics.
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?
The description is front-loaded with the main action and then provides a concise explanatory sentence. The long list of operations is a single sentence but provides valuable reference data. No wasted words, though the list is necessarily lengthy.
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 discovery tool with no output schema, the description explains the purpose and the first-step requirement. It lists all operations so the agent knows what to expect. It could mention the query parameter's role in filtering, but the schema covers that, making the description adequately complete for its complexity.
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 one parameter (query) with 100% description coverage. The tool description does not add any additional meaning to the parameter, so the schema carries the full weight. 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 states the tool's verb and resource: "List the available meet operations." It distinguishes itself from sibling discover tools by explicitly naming the meet scope and enumerating the specific operations it returns, making its purpose unambiguous.
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 provides explicit usage guidance: "call this first, then call the tool you need by name." It explains that operational meet tools are hidden until discovered, establishing a clear prerequisite. However, it does not explicitly mention when not to use this tool or name alternatives, though the sibling list implies service-specific discover tools.
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?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds a key behavioral trait: 'Operational tasks tools are hidden until discovered.' This discloses the discovery mechanism and the need to call this tool before others, which is valuable context. No contradiction with annotations exists.
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?
The description is front-loaded with the primary action and usage directive, followed by a comprehensive list of operation names. While the list is long, it is directly relevant and structured. It avoids fluff and remains efficient overall.
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 discovery tool with one optional parameter and no output schema, the description adequately covers the workflow: call this first, discover operations, then call the needed tool. It explains the hidden-tool behavior and optional filtering. The lack of return-format details is acceptable given the simplicity and absence of an output schema.
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 fully describes the single optional 'query' parameter as a keyword filter, so schema coverage is 100%. The description's list of operation names gives context for what might be filtered but does not add new parameter semantics beyond the schema. This meets the baseline for 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 clearly states 'List the available tasks operations,' providing a specific verb and resource. It distinguishes from sibling discover tools by focusing on 'tasks' and listing the specific operations, making the tool's purpose unambiguous.
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 instructs to 'call this first' before other tasks tools, establishing a clear when-to-use directive. It explains that operational tasks tools are hidden until discovered, which is important context. However, it does not explicitly mention alternatives for other services, though the naming convention implies this is the tasks-specific discovery entry point.
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?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description reveals the discovery mechanism ('hidden until discovered') and lists the exact operations available. This gives important context about how the tool behaves and what the agent can expect. It does not detail return format or rate limits, but the annotations already cover safety, so this is sufficient.
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?
The description is front-loaded with purpose, then usage, then a comprehensive list of operations. The list is long but informative, helping the agent understand the scope without needing to call the tool first. It is structured and each sentence contributes value, though the list could be considered slightly verbose.
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 discovery tool with one optional parameter and no output schema, the description is quite complete. It explains the tool's role, when to use it, and what operations will be available. The absence of return-format details is mitigated by the operation list. It lacks explicit mention of pagination or response structure, but overall it provides sufficient context.
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 covers 100% of the parameter, with the query parameter described as 'Keyword to filter the returned operations.' The description does not add further details about the parameter's format or behavior, so the baseline of 3 applies. The description's listing of operations could hint at what to filter, but it is not explicit.
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 and resource: 'List the available docs operations.' It clearly distinguishes this from sibling tools like drive_discover by focusing on 'docs operations' and enumerating the exact operation names. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Operational docs tools are hidden until discovered — call this first, then call the tool you need by name.' This provides clear usage context and directs the agent to use this tool before other docs tools. It also implies the alternative is calling the named operation directly after discovery.
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 declare this as a read-only, open-world, non-destructive operation. The description adds that it returns method IDs and parameters specifically for invoking via google_api_call, which is useful behavioral context beyond the annotations.
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?
The description is front-loaded with the core purpose, and the API list is the main source of length. It is somewhat long but each element is relevant; the list could arguably be trimmed but serves as documentation of valid aliases.
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?
The tool is relatively simple with only three parameters and no output schema. The description covers the workflow (search then call via google_api_call) and the scope (APIs covered), which is adequate. It lacks explicit pagination or return format details, but maxResults and 'method ids + parameters' partially cover that.
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 schema describes query and api but not maxResults. The description adds a comprehensive list of valid api aliases, providing meaningful guidance for the api parameter that the schema lacks. However, maxResults semantics are still inferred from the name and schema constraints.
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 function: searching the Google API Discovery index for Workspace REST methods, including those without dedicated tools. It distinguishes itself from the sibling discover tools by covering all APIs listed, and the phrase 'with no dedicated tool here' explicitly differentiates its broader scope.
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 this tool: when a method may not have a dedicated discover tool, and it explains how results feed into google_api_call. However, it does not explicitly state to prefer the dedicated per-API discover tools when available, so it provides clear context but not explicit exclusions.
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 reveals an important behavioral trait: 'Operational searchconsole tools are hidden until discovered.' This adds value beyond the readOnlyHint annotation. It doesn't elaborate on return format or filtering, but the readOnly annotation already informs about 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?
The description is concise: it leads with purpose, adds a clear usage instruction, and lists the operations. The list is long but necessary for a discovery tool. No extraneous wording.
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 this is a simple discovery tool with good annotations and full schema coverage, the description adequately explains the hidden-tools mechanism and what to do next. It doesn't mention the query filter, but that is covered by the schema.
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 fully documents the only parameter 'query' with a description ('Keyword to filter the returned operations'). The tool description adds no additional semantics, so the baseline of 3 applies for 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 clearly states the tool's purpose: 'List the available searchconsole operations.' It uses a specific verb (List) and resource (searchconsole operations), and it distinguishes from sibling discover tools by specifying searchconsole.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'call this first, then call the tool you need by name,' which clearly indicates when to use this tool and the workflow. It also provides the list of operations, making the next steps obvious.
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 declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the key behavioral detail that operational workspaceevents tools are 'hidden until discovered' and that this tool reveals them—valuable context not in annotations. It doesn't mention response format, but for a list/discovery operation this is acceptable.
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?
The description is front-loaded with the primary purpose and usage instruction. The long list of operation names is necessary content for a discovery tool, but it adds length. Overall, every sentence serves a purpose and the structure is clear.
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?
The tool is a simple discovery operation with good annotations and full schema coverage for its single optional parameter. The description explains the hidden-tool mechanism and lists all discoverable operations, making the tool's behavior self-contained. No output schema exists, but the description's operation list partially substitutes for that.
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 has one optional parameter 'query' with a description 'Keyword to filter the returned operations', so schema coverage is 100%. The description adds no additional parameter semantics beyond the schema, 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.
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: 'List the available workspaceevents operations.' It uses a specific verb ('List') and resource ('workspaceevents operations'), and the discovery role is distinct from sibling discover tools. The enumeration of operation names further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool: 'call this first, then call the tool you need by name.' This provides a clear sequential workflow, and the context of sibling discover tools makes it obvious that each discover tool covers a different service. No alternatives are excluded but none are needed.
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 declare readOnlyHint=true and destructiveHint=false, and the description complements this by explaining the 'hidden until discovered' behavior. It adds context about operational tool visibility without contradicting annotations.
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?
The description is front-loaded with its purpose and usage guidance, then lists discoverable operations—necessary detail for a discovery tool. The list is long but each item is meaningful, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, no output schema, and read-only annotations, the description covers the tool's purpose, prerequisite behavior, and expected output (operation names). This is sufficient for an agent to select and invoke it correctly.
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 describes the 'query' parameter with 100% coverage, so the description need not elaborate. The description's operation list provides implicit guidance on filterable content, but no additional parameter semantics beyond 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 'List the available calendar operations' with a specific verb and resource. It differentiates from sibling discovery tools (gmail_discover, drive_discover) by specifying calendar-specific operations and the discovery-first workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'call this first, then call the tool you need by name', establishing when to use it. This also implies that other calendar tools are not usable until this discovery step, providing clear usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the discovery mechanism (hidden until called), which is useful behavioral context beyond the annotations.
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?
The description is front-loaded with the core purpose and usage instruction, followed by a comprehensive operation list. While the list is long, it is necessary for a discovery tool and each entry is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity discovery tool with no output schema, the description fully explains the tool's behavior and enumerates all discoverable operations. No additional context is needed.
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 fully describes the single optional 'query' parameter (100% coverage), and the tool description does not mention it. With high schema coverage, a baseline 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 'List the available sheets operations' with a specific verb and resource. It distinguishes itself from sibling discovery tools by being sheets-specific and by indicating it reveals hidden operational tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'call this first' and then call the needed tool by name, with the rationale that operational tools are hidden until discovered. This provides clear when-to-use 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 declare readOnlyHint=true and destructiveHint=false, and the description adds value by detailing the return fields and token health states, giving the agent a clear picture of what the tool reports. It does not discuss side effects, but for a read-only list operation, this is adequate.
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, dense sentence that front-loads the action ('List') and packs all key information: resource, fields, and usage guidance. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description fully specifies what the tool returns and when to use it. It covers the account fields and token health states, making the tool's behavior predictable and complete for its scope.
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, and the schema is trivially covered. The description appropriately does not invent parameter details. The baseline of 4 for zero-parameter tools applies, and the description adds no unnecessary parameter semantics.
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 lists configured Google accounts and enumerates the specific fields returned (alias, email, admin flag, token health, scopes). This specific verb+resource usage distinguishes it from sibling discovery tools, which focus on API discovery rather than account listing.
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 provides explicit usage context: 'Use this to see which account aliases are available and healthy.' While it does not name alternatives or explicitly state when not to use it, the context is clear and sufficient given the absence of similar account-listing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses a key behavioral trait: 'Operational gmail tools are hidden until discovered.' This explains why this tool must be called first and sets expectations for how the tool system works. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage in the first two sentences, then provides a comprehensive list of operations. While the list is very long, it is necessary and directly supports the tool's purpose. It is structured but could be seen as verbose due to the exhaustive enumeration.
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 no output schema, the description compensates by listing all available operations, giving the agent a clear expectation of the return content. It also explains the discovery mechanism and ordering. Slightly more detail on the return format (e.g., list vs. table) would make it complete, but the essential information is present.
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 describes the 'query' parameter with 100% coverage ('Keyword to filter the returned operations'). The description does not add any additional meaning to the parameter itself, but it does list the operations that would be returned, which adds context to the tool's output rather than the input. 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 opens with a specific verb and resource: 'List the available gmail operations.' This clearly distinguishes it from sibling discover tools (e.g., drive_discover, calendar_discover) which target other services. The explicit operation list further confirms the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'call this first, then call the tool you need by name.' This tells the agent exactly when to use it and implies that other gmail tools should be called after discovery. The sibling discover tools provide obvious alternatives for non-Gmail services.
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 indicate readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description adds that it returns JSON only and is subject to the same write-control policy as named tools. This covers mutation risk and response format, though it could mention rate limits or scopes.
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?
Three tightly packed sentences deliver purpose, usage, and key constraints without wasted words. The lead sentence is immediately informative and the structure front-loads the core action.
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 no output schema and a generic catch-all tool, the description covers the essential context: how to discover methods, what to avoid (binary/file content), and the write-control policy. It could note that returns are structured JSON for read methods, but the provided guidance is adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description adds value by explaining that pathParams fill {placeholders} in the method path and that queryParams support arrays for repeated params. It does not repeat per-parameter details, appropriately deferring to 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 it invokes any Google Workspace REST method by Discovery id, explicitly framing it as an escape hatch for operations without a dedicated tool. It distinguishes itself from named tools and directs users to google_api_search for method discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'escape hatch for operations without a dedicated tool' and 'Find methods with google_api_search first.' It also names alternatives (drive_download/drive_export) for specific cases and notes the write-control policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by revealing that operational contacts tools are hidden until discovered and enumerating all operation names. This adds valuable behavioral context about the discovery workflow, which is not available from the annotations alone.
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 efficient: it states the core purpose in the first sentence, gives a clear usage instruction, and then lists operations. The list is necessary content for a discovery tool and adds no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers everything needed: what it does, when to call it, and what operations are available. No output schema exists, but the enumeration of operations provides sufficient context about the expected output (the list of names).
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 already fully documents the single optional 'query' parameter with a clear description. The tool description adds no additional parameter-level semantics, but schema coverage is 100%, so 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 states the tool lists available contacts operations, using the specific verb 'list' and resource 'contacts operations'. It also distinguishes from sibling discovery tools by being contacts-specific and explains the hidden-tools mechanism, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'call this first, then call the tool you need by name', providing clear when-to-use guidance. This is a definitive usage directive that positions the tool as the entry point for all contacts operations, and there is no ambiguity about its role.
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-multi MCP server](https://glama.ai/mcp/servers/bakissation/mcp-google-multi/badges/card.svg)](https://glama.ai/mcp/servers/bakissation/mcp-google-multi)

Score Badge

Copy to your README.md:

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

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/bakissation/mcp-google-multi'

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