sophos_get_health_scores_history

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not disclose any traits such as whether the operation is read-only, rate limits, required permissions, or what happens if no data exists for the date range. While the name suggests a safe read operation, the description lacks sufficient behavioral context.

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 description is a single sentence, 9 words, and front-loaded with the action. It is efficient and avoids unnecessary detail. While it could include more context without becoming verbose, it is appropriately sized and not wasteful.

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 has 3 parameters and no output schema, the description lacks information about the return format, pagination, error handling, or what constitutes a 'health check score'. The purpose of tracking improvement is stated, but without details on how to interpret the results or handle edge cases, it is not complete enough for an agent to use without assumptions.

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?

The input schema covers 100% of parameters with clear descriptions (ISO 8601 dates, UUID, inclusive range). The tool description adds no extra meaning beyond the schema. Per the scoring guidelines, when schema coverage is high, the baseline is 3, indicating the description does not need to compensate.

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 clearly states the verb 'Get', the resource 'historical account health check scores', and the target 'tenant'. The phrase 'to track improvement over time' adds context for why you'd use it. While it doesn't explicitly distinguish from siblings like 'sophos_get_account_health' or 'sophos_get_regional_health_scores', the word 'historical' implies it's for past data, which differentiates it from a current snapshot.

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 provides no explicit guidance on when to use this tool versus alternatives. There is no discussion of prerequisites, when to avoid it, or which tool to use for current health scores (e.g., sophos_get_account_health). The implied usage is for trend analysis, but it's not specific enough to help an agent decide between similar tools.

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