Skip to main content
Glama
gwsadm-mcp

gwsadm-mcp

by shigechika

daily_brief

Aggregate login audits, account-protection changes, and external Drive sharing across all configured domains into one security summary, flagging suspicious activity and partial scans.

Instructions

One-call security summary across all configured domains.

Aggregates login_audit (account locks, suspicious logins), account-protection changes (account_changes: 2-Step Verification enrolled/disabled, passkeys added/removed, Advanced Protection turned off, password and recovery address/phone edits, mail forwarding out of the domain; each row says whether it came from outside the GWSADM_SITES_INI table and from which country (GWSADM_IP2ASN), and is flagged with flag_reasons -- foreign (outside GWSADM_HOME_COUNTRIES), unknown_origin, after_suspicious_login -- flagged rows first, at most 50 listed, total counts all; suspicious_login_coverage says whether the last reason is complete) and drive_external_sharing (external grants, new link exposure, and untargeted_external_transitions — see that tool's docstring). max_pages / samples are passed through to the drive scan; max_pages defaults to the same page budget as the standalone tool, so both report the same counters for the same window (samples defaults lower here and only trims the example lists). Per-domain capped in the summary means at least one underlying scan was partial — treat that domain's counts as lower bounds (see capped_events in the drive section for which probes were cut short).

Synchronous: on a large tenant this can exceed a client's ~60s tool-call timeout. If it does, use daily_brief_start + daily_brief_result (same result, run in the background) or lower max_pages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "daily_brief"
  }
}

Input Schema

NameRequiredDescriptionDefault
hoursNo
samplesNo
max_pagesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/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 well: it discloses that the tool is synchronous, may exceed a ~60s timeout, has a background alternative, and that per-domain 'capped' results mean counts are lower bounds. It also explains flagging semantics and coverage limitations. It stops short of stating permission or auth requirements, which keeps it from a 5.

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 purpose is front-loaded, but the body is a dense single paragraph with nested parentheticals, config-table references, and a pointer to another tool's docstring. Most details are relevant, but the structure makes it harder to scan than necessary for 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 complex aggregate tool with no annotations, no output schema, and 0% schema descriptions, the description covers a lot: aggregation scope, flag reasons, capped/partial-result semantics, timeout behavior, and background alternatives. The main omission is the hours parameter and any auth/permission context, but overall it is substantially 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?

Schema description coverage is 0%, so the description must compensate. It meaningfully explains max_pages (passthrough to the drive scan, default page budget) and samples (passthrough, lower default, only trims example lists), but it never mentions the hours parameter at all, leaving one of three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'One-call security summary across all configured domains,' and then names the exact underlying scans it aggregates (login_audit, account_changes, drive_external_sharing). It clearly distinguishes itself from sibling tools by being an aggregate summary, and it explicitly routes timeout-sensitive callers to daily_brief_start/daily_brief_result.

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?

Usage is clear: use this for a one-call cross-domain security summary, and if the synchronous call exceeds the client timeout, use daily_brief_start + daily_brief_result or lower max_pages. The description does not explicitly state when to prefer the individual domain tools over this aggregate, but the intended context is strongly implied.

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