get_login_history

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, and it discloses almost nothing: no mention of pagination behavior (despite scroll_id and batch_size parameters), no statement about the access_type filter, no note on time-range semantics, and no indication of what the returned records contain. For a data-retrieval tool with zero annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is terse with zero wasted words, which is good for conciseness, but at seven words it is under-specified rather than appropriately sized given the tool's 7 parameters and 0% schema coverage. There is no front-loading of constraints, parameter hints, or usage context, so it reads as a stub rather than a deliberately concise definition.

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

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

Given the tool's complexity (7 parameters, 4 required, no annotations, 0% parameter descriptions), a one-sentence description is grossly inadequate. An agent cannot correctly construct a call without knowing what zoid, mode, access_type, and the time range represent. While an output schema exists, that does not offset the missing input-side semantics and behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 at least the key parameters, but it names none of them. The meaning of zoid, mode, access_type, scroll_id, batch_size, and the integer time fields is entirely unexplained in both the schema and the description, leaving agents to guess at required values.

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

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

The description uses a specific verb ('get') plus a clear resource ('login history') scoped to 'organization', so an agent can tell what the tool operates on. However, it does not distinguish itself from the sibling get_audit_records, which could plausibly overlap with login history, so it misses the sibling-differentiation that would earn a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives such as get_audit_records, no mention of prerequisites (e.g., required time range), and no indication of whether this is for admin/security investigation use cases. The single sentence implies a usage context but provides no exclusions or routing logic.

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