Skip to main content
Glama
gwsadm-mcp

gwsadm-mcp

by shigechika

get_user

Look up one named Google Workspace account to diagnose sign-in failures: suspension reason, archive status, 2-step verification, last login, org unit, and pending password change.

Instructions

Look up ONE named account's current state — the "why can't this person sign in" tool.

Answers a helpdesk ticket that already names the exact address: is the account suspended (and for what reason, since when), archived, enrolled in or enforced into 2-step verification, when did it last log in, which org unit is it in, is a password change pending. One Directory API request, no pagination.

Use this — not suspended_accounts — whenever the address is known. That tool lists only accounts that ARE suspended, so it can never confirm that a given address is not suspended, and once that list exceeds its page cap absence stops being evidence either way — after spending far more API calls than this. suspended_accounts is for the domain-wide sweep it is actually named for.

This directory is downstream of the identity provider, not the master. Read the answer as "what Google Workspace currently believes about this account" and compare it against the IdP's own record, which is authoritative for who the account is. A disagreement is usually drift on this side rather than a mistyped address — an account the IdP still authenticates can be suspended or archived here, and an address the IdP does not assert at all will simply come back found: false.

An address that names no account returns found: false with no state fields. That is a normal, expected answer — a typo'd or long-deleted address — and is itself the diagnostic result, NOT a failure. A missing DWD scope, a rejected credential or a transient API failure is reported as {"error": ...} instead. The two are deliberately distinct: never read found: false as "the lookup did not work", and never read an error as evidence about whether the account exists.

Read-only (Directory API users().get; this tool never changes the account). Requires the admin.directory.user.readonly DWD scope — the same one suspended_accounts uses, so a tenant already running that tool needs no additional grant.

Args: username: Exact user email, passed through as the Directory API userKey (primary or alias address both work on Google's side; the returned email is the account's canonical primary one). domain: Configured [domain.*] section to route the lookup through. Default: resolved from the username's suffix. Set it explicitly when the address uses an alias/secondary domain that has no config section of its own (common when copying addresses from mail headers or IdP logs).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "username": "<username>"
    },
    "name": "get_user"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainNo
usernameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: read-only (`users().get`, "never changes the account"), the required `admin.directory.user.readonly` DWD scope and that it is shared with the sibling, one request with no pagination, and the deliberate `found: false` vs `{"error": ...}` split. It also discloses the important caveat that this directory is downstream of the IdP and can drift.

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 the core purpose in the first line, then layered caveats in descending priority. It is long and the IdP-drift paragraph is somewhat expansive relative to the rest, but every section still contributes decision-relevant information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations, yet the description explains return shape (state fields listed, `found: false` with no state fields, distinct error object), auth prerequisites, and the authoritative-vs-cached semantics of the data. An agent has everything needed to call it and to interpret the result 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 do the work, and it does: `username` is documented as passed through as the Directory API `userKey`, accepting primary or alias addresses, with the note that the returned `email` is canonical. `domain` is documented as a config section selection with default resolution from the username suffix and an explicit rule for when to set it (alias/secondary domains from mail headers or IdP logs).

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?

Opens with a specific verb and resource ("Look up ONE named account's current state") and frames the job as the "why can't this person sign in" tool. It explicitly distinguishes itself from the sibling `suspended_accounts` by explaining what that tool can and cannot answer, so an agent can choose without opening either schema.

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?

Gives an explicit routing rule: "Use this — not suspended_accounts — whenever the address is known," backed by reasoning about page caps and false-negative limits in the sibling. It also states when a `found: false` result is the expected diagnostic answer versus when to expect an error envelope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.