knowbe4_groups_risk_score_history

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description says 'risk score history over time' but doesn't disclose return structure, whether this is a read-only operation, whether it requires permissions, how many data points are returned, or what the time-series looks like. With zero annotation coverage and no output schema, this leaves the agent guessing about behavior.

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?

Two concise sentences with no filler. The first gives the purpose, the second offers a contextual use case. Tight and readable, though it could front-load more critical behavioral info if any existed.

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?

This is a time-series/multi-result tool (pagination parameters suggest many data points) with no annotations, no output schema, and only basic parameter coverage. The description doesn't explain what the returned history contains (data points, timestamps, risk bands), how far back the history goes, or how pagination interacts with time. For a relatively complex reporting tool, this is under-specified.

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 100% — all three parameters (page, group_id, per_page) are documented in the schema with descriptions. The description adds minimal param value ('group' context), so baseline 3 is appropriate. It doesn't explain pagination implications or how risk score history is bucketed over time, but it doesn't need to since the schema already covers the parameters.

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 specifies a clear verb+resource: 'Get a group's risk score history over time.' It names the resource (group) and the specific data (risk score history). It partially distinguishes from siblings (e.g., knowbe4_account_risk_score_history, knowbe4_users_risk_score_history) by explicitly scoping to 'a group,' but doesn't reference those siblings by name.

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?

The description adds a usage context: 'Useful for comparing security posture across departments or teams.' This gives an implicit sense of when to use it, but there are no explicit when/when-not instructions or named alternatives. Since sibling risk score history tools exist (account, users, groups), the lack of explicit differentiation is a gap, though the 'comparing across departments' framing helps.

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