gwsadm-mcp

Server Quality Checklist

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

Latest release: v0.14.1
Disambiguation5/5
Each tool has a clearly distinct purpose: health check, user lookup, group membership, group policy, email trace, drive sharing audit, doc activity, shared drive membership, login audit, suspended accounts, OAuth tokens, and brief variants. No two tools overlap in function, and descriptions carefully distinguish related concerns (e.g., list_group_members vs group_delivery_policy).
Naming Consistency4/5
Most names follow a descriptive pattern, but there is a mix of verb-first (list_group_members, get_user), noun-first (suspended_accounts, user_oauth_tokens, drive_doc_activity), and bare nouns (health_check, daily_brief). The inconsistency is minor and does not hinder comprehension, but a uniform verb_noun scheme would be cleaner.
Tool Count5/5
14 tools is on the higher end of the ideal 3–15 range, but each tool serves a distinct and necessary function for a Google Workspace admin audit server. The count is justified by the breadth of read-only operations covered, with no redundancy or bloat.
Completeness5/5
The tool set comprehensively covers the core read-only audit surface of Google Workspace: user state, group membership and policy, login/security events, Drive sharing and activity, shared drive membership, email delivery tracing, OAuth token review, and aggregated daily briefs. No obvious gaps remain for the server's stated purpose.
Average 4.7/5 across 13 of 14 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits in the last 12 weeks
- Last stable release on August 20, 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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does an excellent job disclosing semantics: it explains what account_disabled_spamming means, that some events are warnings, and that results may be capped. It is very transparent about behavior.
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 is lengthy and somewhat repetitive (e.g., the account_disabled_spamming explanation appears twice). It is not overly verbose but could be tightened without losing essential context.
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 description gives rich context about the tool's purpose, interpretation of results, and how to combine with other tools. However, it does not explain the parameters or provide an output schema, leaving some aspects undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the parameters (top, hours, domain, include_failures). Since schema descriptions are absent (0% coverage), the description fails to compensate for the missing parameter documentation.
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 audits login events and specifically answers the question about Google-disabled accounts, distinguishing it from sibling tools like suspended_accounts or gmail_message_trace.
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?
It provides context on when to use (audit logins, interpret disabled accounts) and even suggests combining with a Directory snapshot, but it does not explicitly contrast with alternative tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Transparently describes the four possible statuses and their implications, including security-conscious error handling (omitting message). Discloses expected polling behavior.
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?
Short and front-loaded with the main purpose. Uses code formatting for clarity. Every sentence adds value; no unnecessary words.
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 (1 param, no output schema), the description sufficiently covers the polling mechanism and response structure. Lacks only some detail on the 'result' payload, but acceptable for a poll-for-result tool.
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?
Schema coverage is 0%, so description must compensate. It mentions fetching 'by id' but does not elaborate on the job_id parameter's format, constraints, or source. Limited added value beyond the parameter name.
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 it fetches a daily_brief_start job by id. Distinguishes from siblings like daily_brief_start (which creates the job) and other unrelated tools.
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?
Explains polling logic: status values and actions (running->poll, done->parse result, error->handle error type, unknown->bad id). Provides clear context for use after starting a job, but doesn't explicitly compare with siblings.
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?
Describes immediate return, async nature, and two error states (config error, job rejection). No annotations provided, so description carries full burden. Could mention authorization needs or job lifecycle beyond polling, but adequate.
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?
Well-structured: front-loaded with purpose, then usage details and error states. A bit wordy but effective.
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?
Covers the necessary async flow with polling. Sibling tools provide the sync version and result fetcher. No output schema, but the polling mechanism is described. Could mention default values and parameter constraints.
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?
Schema has three parameters (hours, samples, max_pages) with defaults but no descriptions. Description says 'Args mirror daily_brief' but does not explain their meaning or effect. With 0% schema description coverage, this is insufficient.
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 it starts a daily_brief in the background and returns a job_id. Differentiates from sibling tool daily_brief (synchronous call) by highlighting async behavior.
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 says when to use this tool (when synchronous call risks timeout for large tenants) and what to do after (poll daily_brief_result). Also covers error responses.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool is lightweight (one query per domain) and always returns the same keys, implying idempotency. It does not explicitly state it is read-only, but the verb 'report' strongly suggests no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences, no wasted words. It front-loads the purpose and then adds key details (return keys, performance). Every sentence earns its place.
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?
Given zero parameters and no output schema, the description fully covers what an agent needs: what the tool does, what it returns, and that it is lightweight. No gaps remain for effective invocation.
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?
There are zero parameters, and schema coverage is 100%. The description adds value by detailing the output keys and performance characteristics, going beyond what the empty schema provides.
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 explicitly states the tool reports 'service status, version, and per-domain auth/API reachability', using a specific verb-report and resource-health check. It distinctly differs from sibling tools like daily_brief or login_audit, which address other aspects.
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 clearly implies use for checking system health, and the sibling context makes the purpose unambiguous. However, it lacks explicit guidance on when not to use it or alternatives, though none are obviously needed given its unique function.
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?
No annotations are provided, so the description carries full burden. It meticulously discloses behavioral traits: exclusions (self-grants, shared drive propagation), limitations (capped events, event errors), and handling of ambiguous cases (missing target_user).
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 is very long but packed with necessary details. While each sentence adds value, the length could be trimmed by grouping related caveats. However, the structured flow (starting with core purpose, then details, then caveats) is logical.
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?
Given the tool's complexity (4 parameters, no output schema, many edge cases), the description is remarkably complete. It covers caveats, error conditions, relationships to sibling tools, and provides actionable advice for triage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description implicitly adds meaning to parameters: 'hours', 'domain', 'samples', and 'max_pages' are discussed in context (e.g., 'Narrow hours or raise max_pages'). However, it does not explicitly map each parameter to its purpose, slightly reducing clarity.
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 reports Drive ACL grants to external targets and new link/public exposure, with a specific verb and resource. It also distinguishes from sibling tools like drive_doc_activity and shared_drive_membership_changes by mentioning them in the shared-drive caveat.
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 provides explicit usage guidance: when to narrow hours or raise max_pages, and when to use alternative tools (drive_doc_activity, shared_drive_membership_changes). It also explains when not to trust counts (capped events) and how to interpret results.
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 transparently explains behavior: it returns 'found: false' for nonexistent accounts, distinguishes that from errors, notes the directory is 'downstream of the identity provider' (data may be stale), and states it is read-only with the required scope. This goes beyond any annotations (none provided) and gives a thorough understanding of side effects and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose and repeats the exact same content in three separate paragraphs (e.g., the 'found: false' and 'read-only' points appear three times). A single concise paragraph would suffice, making the current structure wasteful and harder to parse.
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?
Despite the verbosity, the description is complete: it covers purpose, usage, behavioral nuances (stale data), error handling, scope requirements, and alternatives. It does not need an output schema since none is provided, but it gives sufficient context for an agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains both parameters, despite 0% schema coverage. For 'username', it clarifies that aliases work and the returned email is canonical; for 'domain', it explains the default behavior and when to set it explicitly. This adds significant meaning beyond the raw schema definitions.
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 as 'Look up ONE named account's current state' and explicitly differentiates it from the sibling tool 'suspended_accounts' by stating 'Use this — not ``suspended_accounts`` — whenever the address is known.' This provides a specific verb and resource, and distinguishes it from alternatives.
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 gives explicit usage conditions: 'Answers a helpdesk ticket that already names the exact address' and contrasts with the sibling tool: 'That tool lists only accounts that are suspended...' It also explains when not to use it, providing clear guidance on when to choose this tool over alternatives.
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?
Fully discloses behavior: read-only, Directory API call, query parameter, required scope, error behavior for missing grants, pagination with 'capped' flag, and domain-specific coverage. No annotations, so description carries full burden.
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?
Front-loaded with main purpose, then adds details. Each sentence adds value, but slightly verbose. Good structure with examples and clarifications.
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?
Covers key behavioral aspects, but lacks output schema details (e.g., fields in the returned account list). Mentions 'capped' flag but not the response format. Still complete enough for most use cases.
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?
Adds meaning beyond schema: domain is optional and restricts scope; max_pages controls page count and 'capped' indicates more results. Schema coverage is 0%, so description compensates well, though could be more structured per parameter.
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 returns a 'Snapshot of currently suspended Google Workspace accounts, per domain.' It uses specific verbs and resources, and distinguishes itself from the sibling 'login_audit' by contrasting event vs. state.
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?
Explicit guidance on when to use (cross-reference against IdP for security gaps) and when not (vs. login_audit for events). Also states prerequisites like DWD scope and domain configuration.
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?
No annotations provided, so description bears full burden. Discloses synchronous timeout risk, parameter pass-through behavior, and the 'capped' indication for partial scans. Also clarifies that samples defaults lower and only trims example lists.
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?
Well-structured with clear paragraphs and backticks for terms. Informative but somewhat lengthy; every sentence adds value, but could be slightly more concise.
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?
Given 3 parameters, no output schema, and no annotations, the description covers behavioral context, usage guidelines, parameter semantics, and result interpretation (capped). It is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. Explains that max_pages/samples are passed through to drive scan, with defaults and interactions. However, the 'hours' parameter is not explicitly described beyond its schema title and default, though its purpose is clear from context.
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 is a 'one-call security summary across all configured domains' and specifies it aggregates login_audit and drive_external_sharing. It distinguishes from siblings like daily_brief_start and daily_brief_result by noting the alternative for timeout handling.
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 guidance: use daily_brief_start + daily_brief_result or lower max_pages if synchronous call times out. Also explains defaults for max_pages and samples, and the meaning of 'capped' in results.
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?
Since no annotations are provided, the description fully explains behavioral traits: it uses a server-side filter, explains how page budget is spent, details events listing vs counts, the meaning of 'events_truncated', and how sibling events from bulk actions are excluded. It also covers limitations like retention and multi-tenant scenarios.
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 well-structured with clear sections and bullet points, but it is somewhat lengthy. However, every sentence adds value and the key information is front-loaded. It could be slightly more concise, but overall it is effective.
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 complexity (5 parameters, no annotations or output schema), the description covers essential aspects like return fields (owner, doc_title, events, etc.), edge cases (empty results, sibling events), and parameter effects. However, a dedicated output schema or more explicit return value documentation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's 'Args' section provides thorough explanations for all five parameters: 'doc_id', 'days', 'domain', 'max_pages', and 'max_events'. It explains their purpose and default behavior, adding significant meaning beyond the schema's titles and default values.
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 provides 'full audit history of one Drive document' including owner, ACL changes, and lifecycle. It also explicitly distinguishes itself as the companion to 'drive_external_sharing', making its purpose and uniqueness evident.
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 gives explicit guidance: use this when you have a 'doc_id' from a sharing finding to determine ownership and history. It contrasts with 'drive_external_sharing' and explains when not to use it (e.g., for sharing findings that haven't been triaged). It also clarifies that an empty result does not prove the document doesn't exist.
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?
With no annotations, the description fully covers behavioral traits: it explains low-volume scanning, the event type, drive field semantics, target_is_external classification, client-side substring matching, and the handling of missing drive names via missing_drive_name. Limitations like API filtering caps are also disclosed.
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 well-structured with a clear first paragraph for purpose and a second for parameters, but it is somewhat lengthy. Every sentence adds value, so it is efficient but not extremely concise.
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?
Given 5 parameters, no output schema, and no annotations, the description covers all essential aspects: input parameters, output fields (drive, target_is_external, missing_drive_name), and behavioral details. It is comprehensive for an effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section explains each parameter in plain language, adding context beyond the schema's types and defaults: e.g., days retention, domain restriction, drive_name substring matching with edge cases, and capping mechanisms. Schema coverage is 0%, so the description fully compensates.
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 provides membership add/remove/role-change history, specifies its purpose in triaging sharing findings, and distinguishes itself from the sibling tool drive_doc_activity as 'the other half'. This is a specific verb+resource with sibling differentiation.
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 when to use the tool (to answer 'who added this external member, and when') and contrasts with drive_doc_activity. It also provides guidance on parameter usage, such as the behavior of drive_name and the limitations of the Reports API.
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?
Despite no annotations, the description fully discloses read-only nature (Directory API tokens().list, never delete), required scope admin.directory.user.security, error on missing scope, and no pagination (full list in one response).
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?
Well-structured: concise lead sentence, then scenario context, technical details, and parameter docs. Every sentence adds value; no redundancy. Length is appropriate for the complexity.
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?
Covers most aspects: purpose, usage, behavior, parameters. Lacks explicit description of return format (e.g., list of objects with fields like scopes, client_id, display_text). However, the guidance on what to check partially compensates. No output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds essential meaning: username as exact email passed as userKey (primary/alias work), domain for routing with default resolution and explicit use for alias/secondary domains. This far exceeds schema-only info.
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 OAuth tokens granted by a user, differentiating itself from sibling tools like login_audit and suspended_accounts by addressing a specific blind spot: malicious OAuth apps using previously-granted tokens without generating new login events.
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 context: use for account-compromise triage when login_audit and suspended_accounts are insufficient. Guides the agent to check scopes for Gmail/Drive access and to ignore Google-owned noise. Also explains domain routing and when to set domain explicitly.
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?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses impersonation via domain-wide delegation, searches including Spam and Trash, the read-only use of messages().list and messages().get (metadata only), the per-recipient error vs. "not found" distinction, the inability to distinguish deleted vs. never delivered, and the ambiguous/match_count cap behavior. This is exemplary disclosure.
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?
Though long, the description is structured into a clear one-line purpose, a rationale paragraph, scope/permission warnings, behavioral caveats, and an Args list. Every sentence adds necessary information for a complex tool, and the front-loaded first sentence immediately answers what the tool does.
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?
Given the sparse schema, absence of annotations, and no output schema, the description provides comprehensive context: return semantics, error handling, ambiguity flags, domain configuration, scope prerequisites, and read-only behavior. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. The Args section explains message_id angle-bracket flexibility and address-shape validation, recipients format and max count, and the domain parameter's default per-recipient resolution and special alias-domain use case. This adds substantial meaning beyond the bare 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 opens with a specific verb + resource + scope: "Check whether a message (by RFC 822 Message-ID) reached specific users' mailboxes." It clearly defines the tool as a targeted per-recipient lookup, distinct from the other sibling tools which focus on health, audits, or drive activity.
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: for a KNOWN Message-ID and a KNOWN candidate recipient list, and explains the absence of a cross-user Workspace API. It gives concrete operational guidance such as the 50-recipient limit, splitting larger lists, domain routing, and the required gmail.readonly DWD scope, making usage conditions unambiguous.
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?
With no annotations provided, the description carries the full burden and excels. It discloses read-only behavior ('only groups().get() is issued'), the required scope and its non-default delegation, and the important nuance that found:false is a normal result for a nonexistent group, not an error. This goes well beyond a simple 'checks policy' statement.
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 well-structured with clear paragraphs: purpose, underlying behavior, read-only/scope, return fields, and args. Every sentence adds value, and the length is justified by the technical complexity and the need to prevent misdiagnosis. It is front-loaded with the most important purpose statement.
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?
Given the absence of an output schema, the description thoroughly explains return fields (who_can_post, allow_external_members, etc.), the found:false edge case, the required scope, and when to use the tool. It is complete enough for an agent to understand the tool's behavior, prerequisites, and expected outputs without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain both parameters. It does: group_email is given an example and described as the group's address, while domain is explained as a routing section with a default resolved from the address suffix. This adds meaningful semantics beyond the bare schema types.
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 'Check a Google Group's own posting/delivery policy — why an external sender's mail never arrived,' a specific verb+resource that immediately clarifies the tool's purpose. It distinguishes itself from siblings like gmail_message_trace by explaining that it checks the group-level policy before Gmail delivery, unlike mailbox-level traces.
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?
Explicit guidance is provided: 'Use this FIRST when a group address "isn't receiving" mail from an external sender, before chasing it as a transport/spam problem.' It also contrasts with gmail_message_trace and Reports-API traces, explaining why this tool is the right first step and excluding alternatives in the same context.
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?
No annotations are provided, so the description fully carries the transparency burden. It discloses read-only behavior, the two Directory API calls issued, required scopes (including per-service-account grant), partial success semantics when one scope is missing, and the meaning of found:false and capped:true, including nuanced edge cases.
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 long but every sentence contributes valuable information. It is structured into clear sections: purpose, comparison with alternatives, read-only/scopes, found/capped semantics, and arguments. The first sentence fronts the primary purpose, and the level of detail is justified by the tool's behavioral complexity.
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?
Given the tool's complexity (3 parameters, no output schema, complex edge cases), the description is exceptionally complete. It covers return behavior, error handling, scope requirements, and interpretation of edge conditions like found:false and capped:true, ensuring the agent can invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains every parameter in detail: group_email as the group's address, domain with default resolution from address suffix, and max_pages with its pagination cap, default, and the meaning of capped:true. This far exceeds the schema's minimal definitions.
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 a specific verb and resource: 'List a Google Group's basic metadata and member roster (Directory API).' It clearly distinguishes from sibling tools like gmail_message_trace and group_delivery_policy by explaining the unique value of resolving actual membership directly, independent of any message having been sent.
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 provides explicit usage guidance: it explains when to pair with gmail_message_trace for deep-diving a member's mailbox and with group_delivery_policy for group-level delivery issues. It also contrasts with the alternative of inferring membership from Reports API delivery-event fanout, clarifying when this tool is preferable.
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:

[![gwsadm-mcp MCP server](https://glama.ai/mcp/servers/shigechika/gwsadm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shigechika/gwsadm-mcp)

Score Badge

Copy to your README.md:

[![gwsadm-mcp MCP server](https://glama.ai/mcp/servers/shigechika/gwsadm-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shigechika/gwsadm-mcp)

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/shigechika/gwsadm-mcp'

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