gws-admin-mcp

by antct11

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.3.0
Disambiguation5/5
Each tool targets a distinct resource and action (get vs list, different resource types like users, groups, devices, reports, etc.). Even similar tools like reports_activities and reports_usage are clearly separated by audit vs usage, and device lists distinguish mobile vs ChromeOS.
Naming Consistency5/5
All tool names follow a consistent resource_operation pattern (e.g., users_list, groups_get, orgunits_list). Some names include a subresource (devices_list_mobile, groups_list_members), but the convention remains uniform and predictable.
Tool Count4/5
17 tools is a reasonable number for a Google Workspace admin server covering users, groups, devices, reports, org units, roles, and domains. It is slightly on the heavier side but each tool focuses on a distinct administrative area.
Completeness2/5
The tool set is almost entirely read-only (get/list/query). There are no create, update, or delete operations for users, groups, devices, org units, roles, or domains, which is a significant gap for an 'admin' server. Management tasks like creating users or updating group settings are impossible.
Average 3.3/5 across 17 of 17 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
This repository includes a glama.json configuration file.
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

Behavior2/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 only says 'List managed mobile devices' with no mention of pagination, filtering behavior, authentication, or risk profile. While 'list' implies a read operation, the description discloses no behavioral traits beyond the action.
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 a single short sentence, 'List managed mobile devices,' which is efficient and front-loaded. However, it borders on under-specification for a tool with two parameters, offering minimal substance beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is still incomplete. It lacks information about the query filter syntax, maxResults constraints, and return format. The presence of sibling tools like devices_list_chromeos suggests shared patterns, but the description doesn't leverage them or provide enough context for reliable invocation.
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 schema has two parameters (query and maxResults) with no descriptions. The tool description does not explain what 'query' does or how maxResults behaves, leaving the agent to infer from types and defaults. With 0% schema description coverage, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List managed mobile devices' with a specific verb and resource, clearly distinguishing it from sibling devices_list_chromeos by resource type. However, it doesn't elaborate on what 'mobile' includes or provide any further distinguishing details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like devices_list_chromeos or users_list. The description provides no use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description discloses no behavioral traits. It does not mention whether this is a read-only operation, whether results are paginated, or any side effects. The burden falls entirely on the description, and it fails to provide any added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, but it is under-specified. It is structurally fine as a single sentence, but the lack of detail makes it borderline between appropriate brevity and inadequate explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is missing essential context. There is no output schema, no annotations, and the parameters are unexplained. This is incomplete for a list tool that has a query parameter and result limits.
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 schema has two parameters (query, maxResults) with 0% coverage in the description. The description does not explain what 'query' does or how 'maxResults' behaves. Since schema coverage is low, the description needed to compensate but did not.
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 'List' and identifies the resource as 'managed ChromeOS devices', which is clear and distinguishes it from sibling tools like devices_list_mobile. There is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description simply states what it does without mentioning any conditions, prerequisites, or comparisons to sibling tools such as devices_list_mobile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It simply says 'Query the audit log' without stating that the operation is read-only, whether it requires special permissions, or what the response contains. It also omits pagination behavior (noted in the schema) and rate limits. This is insufficient for a tool that may access sensitive audit data.
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 a single focused sentence with no filler. It front-loads the main action and provides a helpful list of examples. However, the examples replicate the schema's enum, making them somewhat redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description is minimal and does not cover prerequisites, response format, or use cases of the returned data. It is far from complete for an audit-log querying 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?
The description adds little beyond the input schema. It repeats the applicationName enum values already present in the schema, but does not explain endTime, eventName, or other parameters. With 50% schema description coverage, the description should compensate by explaining these ambiguous fields; it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query the audit log for an application' with specific verb and resource. It also provides a list of applicationName examples (login, admin, drive, etc.), which helps clarify scope. This distinguishes it from sibling tools like reports_usage_user and reports_usage_customer, which are about usage reports, not audit logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention any exclusionary criteria or contrast with sibling tools. The only contextual hint is the applicationName examples, which are parameter details, not usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'List organizational units.' It does not disclose default behavior, such as the 'type' defaulting to 'all', the need for orgUnitPath when listing children, or any read-only assurance. The agent is left without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, 'List organizational units,' which is extremely concise, front-loaded, and contains no filler or redundant information. It is appropriately sized for a tool with such a simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is underspecified. It does not explain return values, filtering logic, or the relationship to sibling tools. The agent must rely on the terse schema, and even that is insufficient for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters beyond what the schema already provides. While the schema has an enum and default for 'type' and a description for 'orgUnitPath', the tool description does not explain how these parameters affect the listing, thus contributing nothing beyond structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List organizational units' clearly uses the verb 'list' and identifies the resource as organizational units, which distinguishes it from getting a specific unit via orgunits_get. However, it does not mention the two listing modes (all/children) visible in the schema, so it is slightly under-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like orgunits_get or other list tools. There are no exclusions, alternatives, or contexts mentioned, leaving usage entirely inferred from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior, but it only states 'list members'. It does not mention pagination via maxResults, the response format, or any limitations on what members are included (e.g., direct vs nested).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters (one required), no output schema, and no annotations, the description is incomplete. It fails to hint at the return structure, pagination behavior, or any edge cases, making it insufficiently complete for an agent to fully understand the tool.
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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention groupKey or maxResults at all, leaving the agent to infer their meaning from the schema alone, which fails the compensation requirement.
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 the specific verb 'list' and the resource 'members of a group', which clearly identifies the operation and distinguishes it from siblings like groups_list (list groups) and groups_get (get group details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, such as groups_get for single group info or users_list for users. There is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only repeats the date format and the 'all' default from the schema. It does not disclose what the report contains, whether it is read-only, or any other behavioral traits such as data scope or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and format. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a report tool with no output schema and no annotations. The description does not explain what the report returns, how it is structured, or any limitations on the date range. For a data-report tool, this is incomplete context for the agent.
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 the date parameter (format) but not userKey. The description adds meaning by explaining the special value 'all' for userKey, which is not in the schema. However, it does not clarify what a specific userKey value represents (e.g., user ID, email), so it only partially compensates for the 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a user usage report for a date (YYYY-MM-DD).' It uses a specific verb ('get') and resource ('user usage report'), and the sibling tool reports_usage_customer implies a distinction at the user vs. customer level, even though that distinction is not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives. The only usage instruction is 'Use 'all' for all users,' which addresses the userKey parameter but does not explain when to use this tool vs. reports_usage_customer or other reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It omits return format, pagination behavior, authentication requirements, and explicitly confirmatory read-only nature; 'List' implies it, but it is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word earns its place. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameter details, but without annotations or output schema the description should specify return values and usage boundaries. It is minimally adequate but leaves gaps in selection and outcome expectations.
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 description enriches the query parameter with concrete Admin SDK syntax examples, adding value beyond the schema. However, orderBy and maxResults are left entirely to schema definitions, and schema coverage is only 33%, so compensation is partial.
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 starts with the specific verb 'List' and resource 'directory users', clearly distinguishing it from users_get. The optional query syntax with examples further clarifies the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like users_get or other list tools. The query examples address filtering, not tool selection, so there are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose behavioral traits beyond what is obvious from 'list'. It does not mention read-only status, pagination, rate limits, or required permissions. With no annotations, the description carries full burden, and it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It states the action first and then the optional filters, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list operation but lacks details on return format, pagination behavior, or whether query and userKey can be combined. The schema covers maxResults auto-pagination, but the description does not reinforce it, and there is no output schema to explain the response structure.
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 description adds meaningful context for query (with an example 'email:sales*') and userKey (listing groups a user belongs to), which compensates for the lack of schema description on the query parameter. The maxResults parameter is left to the schema, but schema coverage is 67% and the extra context is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List groups' with a specific verb and resource, and it distinguishes the tool from siblings like groups_get (specific group) and groups_list_members (list members) by focusing on the list operation. However, it does not explicitly name alternative tools for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by showing optional filters (query, userKey) and gives an example, but it does not explicitly state when to use alternatives or exclude other tools. There is no mention of 'use groups_get for a single group' or similar guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states 'Get' (implying read-only) but does not disclose any details such as authentication requirements, return format, or what 'customer info' includes. This is minimal behavioral 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?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the essential purpose efficiently and is appropriately sized for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no annotations, and no output schema, so the description must stand alone. It states the basic purpose but lacks any detail about what the returned customer info contains, which would be helpful for full completeness. It is adequate but minimal.
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 covers 100% (vacuously). The description does not need to explain parameters. Baseline for zero parameters is 4, and no additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Workspace customer (org) info', making it distinct from sibling tools like users_get or groups_get. It explicitly identifies the target as customer/org-level information, which 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Since it is a simple read, the intended use is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only states 'list', implying a read operation, but does not mention what fields are returned, whether there is any pagination, or any side effects. Minimal 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?
The description is a single, concise sentence that immediately conveys the tool's function. No wasted words, front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description is minimally adequate but incomplete. It does not describe the output format (e.g., role IDs, names), any filtering or sorting behavior, or how it relates to role_assignments_list. This is acceptable given the tool's simplicity but leaves gaps.
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 coverage is trivially 100%. With no parameters, the description does not need to add parameter details. Baseline for zero-parameter tools is 4, and the description is consistent with that.
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?
Description uses the specific verb 'List' with the resource 'admin roles defined in the org', clearly distinguishing it from sibling tools like role_assignments_list which deals with assignments, not roles. Purpose is unambiguous and complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While the description clarifies it lists roles rather than assignments, it does not provide any context or exclusions, leaving the agent without direction on choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get', which implies a read operation, but does not describe the return format, error behavior, permissions, or any side effects. For a simple getter this is minimal but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that front-loads the core action. There is no unnecessary information, making it appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter, no annotations, and no output schema. The description covers the input mechanism but omits return value details and potential usage caveats. It is minimally complete for a simple lookup but not rich.
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 fully documents the single parameter (userKey) with type, description, and required status. The description repeats the 'email or id' detail, adding no new meaning beyond 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 identifies the action ('Get'), the resource ('a single user'), and the lookup method ('by email or id'). This distinguishes it from sibling tools like users_list, which handle multiple users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'single' implies this tool is for retrieving one specific user as opposed to listing users, but there is no explicit guidance on when to use this versus alternatives or prerequisites. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' indicates a read-only operation, which is transparent. However, with no annotations, the description carries full burden for disclosing behavior. It does not mention whether special permissions are required, how the response is structured, or any other side effects. The description is adequate but not rich.
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, focused sentence that efficiently conveys the tool's purpose with concrete examples. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description lists some settings but leaves 'etc.' open-ended. It does not describe the return format or any pagination/error behavior. It is minimally complete but lacks details that would help an agent know what to expect in the response.
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 description coverage is 0%, and the description does not reference the 'groupEmail' parameter at all. While the parameter name is self-explanatory, the description fails to add any explicit meaning beyond the schema's type and property name, which is insufficient given the low 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 function: 'Get a group's access settings'. It specifies the resource (group access settings) and provides examples ('who can join/post/view, archiving, moderation, etc.'), distinguishing it from sibling tools like groups_get which would retrieve general group information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a group's access settings) but provides no explicit guidance on alternatives or exclusions. It does not mention groups_get or other sibling tools, so the context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only restates the action and scope. It does not mention what the report contains, how data is aggregated, access requirements, or any limitations beyond the date format.
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?
A single, front-loaded sentence states the action, the target, and the required input format. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks any detail about what the usage report includes or how it might be returned. The sibling tools and schema provide some context, but the description alone only gives a minimal, though adequate, picture.
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 fully describes the only parameter ('date' as YYYY-MM-DD and a past date), so the description adds no further semantic value. Baseline 3 is appropriate because schema coverage is 100% and the description simply echoes 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 uses a specific verb ('Get') and a specific resource ('customer-wide usage report') with a required date, clearly identifying what the tool does. It also distinguishes itself from sibling tools like reports_usage_user by explicitly noting the 'customer-wide' 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 use for retrieving a customer-wide report for a specific date, providing clear context. It does not explicitly mention when not to use it or name alternatives, but the sibling context and 'customer-wide' qualifier make the usage scenario reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. 'List' implies a read-only operation, and the mention of 'domains and domain aliases' hints at the return content, but it does not mention any limitations, permissions, or pagination behavior. Adequate for a zero-parameter read tool, but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource with no extraneous words. It earns its place perfectly for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters, output schema, and annotations, the description is surprisingly complete for the tool's simplicity. It states exactly what is listed and the scope. A 5 would require additional context about return format or usage notes, but for a zero-param tool this is largely unnecessary.
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, so the schema already provides exhaustive coverage. The baseline for 0 params is 4, and the description need not compensate for missing parameter semantics since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the domains and domain aliases in the org', using a specific verb and resource that distinguishes it from sibling tools, which list users, groups, devices, etc. The scope 'in the org' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states the core action, leaving the agent to infer its applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose any behavioral traits such as read-only nature, error handling, or permission requirements. It only states the action and identifier.
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?
One short sentence with no redundancy, front-loaded with action verb.
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 get operation with one parameter and no output schema, the description is adequate. It specifies the identifier type and the action. However, it could benefit from noting it returns a single group object.
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 has 0% description coverage. Description compensates by explaining that groupKey can be an email or id, adding semantic meaning beyond the schema's bare 'string' type.
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?
Description uses specific verb 'Get' with resource 'group' and identifier method 'by email or id', clearly distinguishing from siblings like groups_list and groupsettings_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. However, 'Get a group' implies single-resource fetch, while siblings like groups_list list groups. The context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Get' clearly implies a read operation and harmless retrieval, but it does not mention behavior for non-existent paths, authorization requirements, or return format. It is adequate for a straightforward get but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence with an example, containing no fluff or redundancy. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter and no output schema, so the description covers the core purpose. However, it omits return value details and error cases, which are relevant for a complete understanding. Given the simplicity, the missing information is not critical but noticeable.
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 provides no description for orgUnitPath (0% coverage), so the description compensates by showing an example path '/Sales'. This adds meaningful context about the expected format, though it does not fully specify path rules (e.g., root path representation).
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 specific action ('Get') and resource ('org unit') with the method of identification ('by path'). The example '/Sales' distinguishes it from list-type siblings like orgunits_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific org unit is needed by path, and the example gives a concrete reference. However, it does not explicitly contrast with alternatives like orgunits_list or state when this tool should be preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It correctly implies a read-only operation via 'List' and adds the optional-user-filter behavior. However, it does not mention pagination, sorting, or any access requirements, which are typical behavioral traits for list tools. This is a minimal but acceptable 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?
The description is a single, tightly worded sentence that immediately states the action and the key optional behavior. No filler or redundant information, ideal for quick scanning by an agent.
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 one-parameter list tool with no output schema, the description adequately covers the purpose and optional filter. It might have benefited from a note on how it differs from related list tools like 'roles_list', but given the low complexity, it is otherwise complete.
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 covers 100% of the parameter documentation, providing a clear description for 'userKey'. The description's 'optionally for a specific user' reinforces the optional nature already indicated by the zero required parameters, but it does not add significant new meaning beyond the schema. 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 uses a specific verb 'List' with the resource 'role assignments' clearly indicating the tool's purpose. It distinguishes from siblings like 'roles_list' (which lists roles themselves) and 'users_list' (which lists users), making the scope 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 phrase 'optionally for a specific user' provides clear context on when to use the optional filter, effectively communicating that this tool can list all role assignments or those for a specific user. However, it does not explicitly name alternatives or exclude other tools, so it stops short of a 5.
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:

[![gws-admin-mcp MCP server](https://glama.ai/mcp/servers/antct11/gws-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/antct11/gws-admin-mcp)

Score Badge

Copy to your README.md:

[![gws-admin-mcp MCP server](https://glama.ai/mcp/servers/antct11/gws-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/antct11/gws-admin-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/antct11/gws-admin-mcp'

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