Skip to main content
Glama
shigechika

gwsadm-mcp

by shigechika

compromise_sweep

Run a read-only post-compromise check for one Google Workspace account: review activity, state, OAuth grants, sweep attacker IPs across domains, and inspect Gmail forwarding, filters, and delegates.

Instructions

The Google-side follow-through after ONE account is confirmed compromised, in one call.

Four questions, each answered from its own source and reported in its own section so that a failure in one never hides the others:

  • activity: what the account did (user_activity for the window, flags first -- a 2sv_enroll from the attacker is the item that survives a password reset). A Reports failure stays in this section as error; the others are still attempted with their own grants.

  • state / grants: what the account is now (get_user: suspended, 2SV enrolled, last login) and which OAuth grants can read or act on content (grants.risky: mail / Drive / contacts / admin scopes; sign-in-only grants are listed but not called out).

  • ips: whether the same sources reached other accounts (ip_activity across every configured domain for the addresses in ips, or, when none are given, for the addresses on the account's own flags -- which include the attacker's, and also the owner's own when they authorized an app or re-authenticated -- capped at SWEEP_MAX_IPS, newest first). The swept account itself is excluded from other_accounts; a shared egress address (a campus NAT, a gateway host that impersonates accounts) legitimately shows other accounts, so read other_accounts against where the address sits.

  • gmail: the settings an attacker leaves behind to keep reading mail (auto-forwarding, forwarding addresses, filters that forward / delete / archive, delegates, send-as aliases and reply-to) plus what the mailbox sent in the window as counts and recipient domains -- never a subject or body. Its kind says whether it could be read at all: ok, partial (a settings section or the sent summary failed -- section_errors / sent.error say which; the rest stands), api_disabled (the Gmail API is off in the service account's own Cloud project), no_grant (no gmail.readonly DWD grant) or error. A failure is reported as such, never as "nothing found".

highlights lists the facts a responder acts on, one line each, and checklist what remains to do or verify by hand (second-factor removal, session sign-out, recovery contacts, message content). Nothing here changes the account; the identity provider's side of the incident (and any other SaaS) stays with the caller.

Read-only: Reports API activities().list, Directory users().get and tokens().list, and Gmail settings.* reads plus messages().list / messages().get(format="metadata") with the To / Cc / Bcc / Date headers only.

Args: username: Exact user email of the compromised account. hours: Window length ending now, for activity, the IP sweep and sent mail. ips: Comma-separated attacker addresses to sweep, at most SWEEP_MAX_IPS (more is refused, not truncated). Default: the addresses on the account's own flags, newest first, same cap. max_pages: Page budget per application for the account's activity (the IP sweep uses its own small budget). max_sent: Sent messages whose envelope is fetched, concurrently (the count covers everything listed). domain: Configured [domain.*] section for the account. Default: resolved from the username's suffix. The IP sweep always covers every configured domain.

Input Schema

NameRequiredDescriptionDefault
ipsNo
hoursNo
domainNo
max_sentNo
usernameYes
max_pagesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.22.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations at all, the description carries the full burden and does so thoroughly: it enumerates the exact read-only API calls, states nothing mutates the account, explains per-section failure isolation ('a failure in one never hides the others'), the ``kind`` enum including ``api_disabled``/``no_grant``, SWEEP_MAX_IPS being refused rather than truncated, and the privacy guarantee that no subject or body is ever returned.

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 purpose is front-loaded in the first line and the body is broken into named sections mirroring the return shape, so it scans well. It is nevertheless long and occasionally digresses into responder nuance (campus NAT, gateway impersonation) that could be trimmed, though most of it does earn 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?

This is a complex multi-source tool with no annotations and no output schema, so the description must explain returns itself — and it does, describing ``highlights``, ``checklist``, per-section error fields and the ``other_accounts`` exclusion rule. An agent has everything needed to call it and interpret partial failures.

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%, yet every one of the six parameters is given meaning beyond its type: ``ips`` including its default derivation, ordering and cap behaviour; ``max_pages`` as a per-application page budget; ``max_sent`` as a concurrent envelope fetch; ``domain`` with its suffix-resolution default. It also explains what ``hours`` scopes across all three sub-queries.

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 precise verb and scope: the Google-side follow-through after ONE account is confirmed compromised, aggregating activity, state/grants, IP sweep and Gmail settings in one call. It is clearly distinguishable from the single-source siblings (user_activity, ip_activity, get_user, user_oauth_tokens) that it fans out to.

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 trigger condition is explicit ('after ONE account is confirmed compromised') and the boundary is stated ('Nothing here changes the account; the identity provider's side ... stays with the caller'). It does not, however, tell the agent when to prefer the narrower siblings (e.g. a single user_activity lookup) over this heavier sweep.

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