Skip to main content
Glama
Sign In
endpoint-aiops-mcp

endpoint-aiops-mcp

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

login_storm_analysis

Read-only

Analyze session records or live endpoints to detect login storms, then rank slowest login and boot contributors by duration and threshold.

Instructions

[READ] Detect login storms + rank the slowest login/boot contributors.

Answers "is this a morning login storm, and which endpoints/users are dragging login and boot times?" Groups logins into storm episodes (>= min_concurrent within a window_s sliding window) and flags sessions slower than the thresholds — every flag is reported with its number, not a verdict. Pass 'sessions' for pure analysis, or a target to pull live via session_list.

Args: since_hours: Live look-back window when sessions is omitted (default 24). window_s: Sliding window that defines "concurrent" logins (default 300). min_concurrent: Logins within a window that constitute a storm (default 10). slow_login_ms: Login duration (ms) flagged as slow (default 30000). slow_boot_ms: Boot duration (ms) flagged as slow (default 90000). sessions: Injected session records — {endpoint, user, login_ms, boot_ms, timestamp (ISO-8601), result}; skips live collection. target: Endpoint-management target name from config; omit for the default. limit: Max rows in each returned list (default 25).

Returns dict: {totalSessions, sessionsReceived, inputTruncated, stormCount, storms:{items:[{start, end, count, peakConcurrent, spanS, distinctUsers, distinctEndpoints, avgLoginMs}], returned, limit, truncated}, slowLoginCount, slowestByLogin:{items[], ...}, slowestByBoot:{items[], ...}, failedLogins, thresholds}. Each list is a truncation envelope — when its 'truncated' is true, re-run with a higher limit; stormCount is the full episode count.

Example: login_storm_analysis(sessions=[{"endpoint":"tc01","user":"a", "login_ms":42000,"timestamp":"2026-07-12T08:00:00Z"}, ...]).

Input Schema

NameRequiredDescriptionDefault
limitNo
targetNo
sessionsNo
window_sNo
since_hoursNo
slow_boot_msNo
slow_login_msNo
min_concurrentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.3
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 25,
+  "title": "Limit",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint annotation: it discloses that every flag carries a number rather than a verdict, that each returned list is a truncation envelope, that re-running with a higher limit is the remedy, and that stormCount is the full episode count. This is unusually rich behavioral context for a read-only tool.

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-loads the purpose and the question answered, then structured Args/Returns/Example sections where nearly every line carries information. It is long, but the length is justified by the 8 params and the missing output schema; a slightly tighter Returns section would be the only trim.

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?

With no output schema and 8 undocumented params, the description supplies the full return envelope (stormCount, storms items shape, truncation flags, thresholds) and an example call, leaving nothing an agent needs to invoke or interpret results.

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 across 8 parameters, the description fully compensates: each arg is documented with its meaning, default, and semantics (e.g. window_s defines 'concurrent', min_concurrent defines a storm, sinced_hours applies only when sessions is omitted). The single biggest schema gap is closed.

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?

States specific verbs and resources: 'Detect login storms + rank the slowest login/boot contributors,' and frames the exact question it answers. This clearly distinguishes it from siblings like session_list or overview.

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 the two operating modes ('Pass sessions for pure analysis, or a target to pull live via session_list'), routing the agent between injected-data analysis and live collection. It stops short of explicit when-not/alternative guidance for cases like simple session lookup, so it does not reach a 5.

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

Deploy Server

Other Tools